[2259] in linux-scsi channel archive
Re: How to skip over tape eof mark
daemon@ATHENA.MIT.EDU (Michael Weller)
Thu Aug 7 06:09:38 1997
Date: Thu, 7 Aug 1997 11:31:17 +0200 (MESZ)
From: Michael Weller <eowmob@exp-math.uni-essen.de>
To: Andy Poling <andy@realbig.com>
Cc: Louis Mandelstam <lma@sacc.org.za>, linux-scsi@vger.rutgers.edu,
glug@linux.org.za, unix-wiz@listserv.nodak.edu
In-Reply-To: <Pine.LNX.3.96.970806124153.3838t-100000@roadrunner.realbig.com>
On Wed, 6 Aug 1997, Andy Poling wrote:
> On Wed, 6 Aug 1997, Louis Mandelstam wrote:
> > I have a tape here (Exabyte 8mm) which had 'mt eof' (write eof
> > marker) executed on it while the tape was wound to the beginning, when the
> > user meant 'mt eod' (seek to end of data). Easy typo that turned out to
> > be surprisingly lethal.
> >
> > I presume the first file will be lost (the first few bytes of it at least)
> > but can anyone tell me how I can manage to get the st driver to skip over
> > this boo-boo so that the rest of the tape can still be accessed?
>
> Sorry, but I think you're SOL. It's the tape drive itself that won't ignore
Yup.
> the eof marker (which is really a filemark - FM). Or, more correctly, it
No, the eof marker is no problem. But the tape drive realized that you did
not write anything after the eof and made a EOD or EOM or however it is
called, mark after that (probably just a small section of erased tape).
The firmware of almost any SCSI drive I know will strictly refuse to go
past that point.
> probably can't deal with the (now) corrupted block after the FM. Remember,
> a tape drive is a linear access device. It really has no concept of random
Well, it depends...
> access. Your linearity was lost when you (this is the "royal you" - i.e.
> they) wrote that FM record over top of your data...
>
> Also, most unix-like tape drivers automatically write two FM's and then
> overwrite the second one when you add another tape file to the tape. Two
> FM's means EOM to a tape drive. According to the st(4) manpage, under
Well, yes it is common to mark EOM by two adjacent EOF. But this is
strictly a feature of the tape driveR . It has nothing to do with the tape
device. The scsi tapes I've access to have their complete own idea of EOM
which does not depend on any number of EOF marks.
Actually, all scsi drives firmware I've access to strictly refuses to
write on a tape when not positioned either at beginning of tape or
EOM (some do even not support the latter (I mean, you can write
sequentially to the tape, but once rewound or esp. removed and reinserted,
the drive will not be able to space to EOD and append to it)).
For those, overwriting the second EOF mark would be impossible.
> Linux this depends upon the MT_ST_TWO_FM option setting.
Which confirms what I said, it is a driveR not a drive feature.
>
> If the data is really important, I'm sure there are companies who specialize
> in pulling the bits off the tape using special drives that can ignore FM and
> EOM...
Yes, certainly. Also, the EXABYTE SCSI drive might have some not (well)
documented non-standard SCSI commmands or mode pages which allow to make
it recover the data.
As a trick, you could try to space to the n-th block of the tape with seek
n. I found that I was able to space on EOF or even EOD marks on tapes (at
least for read access) and sometimes beyond (maybe intentional, maybe due
to buggy firmware). If you are lucky, try 'mt seek n' for some small n and
it will move you behind the EOD mark and you can read from behind the
corrupted spot. If it is a tar, say, it will just seek the start of the
next backup'ed file, and then continue to read, thus you'll probably only
loose the first (few) files.
Again, it might not work, but it is worth a try.
BTW, some SCSI tapes even allow to overwrite certain blocks after a seek
and can thus be used as random access devices. For various OS's (but I
don't think linux) exist drivers which allow to mount a tape and use it
as a harddisk (either read-only, or read-write if the tape supports it).
However, though convenient, the drives hardware is not designed for that.
IT will be slow, the tapes will wear off tremendously fast, the drives
will get dirty by the tape fragments, and all its hardware will wear off
fast (including the tape heads, of course).
Thus, a nice application to impress your friend, but a NO GO for
professional use.
Michael.
(eowmob@exp-math.uni-essen.de or eowmob@pollux.exp-math.uni-essen.de
Please do not use my vm or de0hrz1a accounts anymore. In case of real
problems reaching me try mat42b@spi.power.uni-essen.de instead.)
