SUMMARY: How to skip over tape eof mark (longish)

[Louis Mandelstam <lma@xxxxxxxxxxx>]

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've recieved several responses, both via direct email and as followups on
the lists.

I *have* managed to recover the information I needed from the
tape.

I think it should have been clear from the message body, but the
subject line should really have read "How to skip over tape eod mark".

Cross-posting to three lists was, in hindsight, not as good an idea.  I
just couldn't decide which between Unix-Wiz and Linux-SCSI was more likely
to hold the answer, since I didn't know if it was a Linux-specific problem
or not.  Then I added my local Linux User's Group in for good measure.
Nobody complained, but now I have ;-)

I should also have given more details regarding what I was using.  The OS
is Red Hat Linux 4.1/Intel, and the drive is an Exabyte EXB-8505XL
internal.  The media was Exatape 160mXL.  The tape contained several tars
in series (using the non-rewinding device).

Skipping over eof marks is a no-brainer (many responses recommended
things like 'mt fsf <n>' to move over them.  The problem was getting
over the eod (end of data) mark (saw some other names for it as well).

Turns out that this is more hardware dependant than I thought.  Seems
many drives in this class (4mm, 8mm etc) have firmware which simply won't
let you skip over the eod (often two eofs in series, and in the case of
this drive I saw one mention of it being just noise, and someone else said
it was about 5Mbyte in length).

Gauthier Briere <1386g@xxxxxxxxxxxxxxxxxxxxxx> responded in Unix-Wiz,
saying that one could put the firmware in the Exabyte drive into
"directory mode" (using software available on the Exabyte web site - see 
his message for details) in which it would allow you to pass the eod mark.

I checked the site and downloaded the software, but according to the site
one also needs a so-called "monitor cable" which connects the CTS port on
the drive to your serial port, so that their CTS Monitor software can
communicate with the drive.  I don't have such a cable available to me -
it would take at least a week or two to order one, and I wasn't able to
find the correct connector in order to follow Exabyte's instructions in
order to make the cable myself (well, to have it made for me..)

Some people responded recommending I do something like this:

mt rewind   (rewind to BOT)
dd if=/dev/zero of=/dev/nst0 ifs=1024 count=8

- the intention being that this would overwrite the EOD mark near the
beginning of the tape, and make the rest of the information on the tape
available again.  Problem is of course, after the write is complete, a new
EOD will be appended after it.

A couple of people responded with something similar to the above, but with
the added step of cutting power to the drive while the write was in
progress, but after it would have written over the EOD mark.  Thus it
would not have a chance to write the new EOD mark, effectively leaving the
beginning of the tape corrupted, but giving us access to the rest
of the tape.

I didn't like this idea at first (I expected to find an option I can set
on the drive via a SCSI command, quite simply - but that never
materialized) but it grew on me eventually, so I tried it with a test tape
this morning, found the technique to work, and managed to recover my tape
with only the beginning of the first tar damaged - in this case that was
no loss at all.

There were some complications however in my case:

1. I'm using an internal drive - cutting the power would require removing
the machine from the rack, and meddling with its insides while it's
running - which is certainly not impossible but worth avoiding if
possible.

I solved this by downing the machine (the tape drive is accessed by "real"
servers over the network, not via direct SCSI - I learnt to do that long
ago), and mounting its disks read-only, so that I could safely cut power
to the entire machine when the time came.


2. Also, the Exabyte seems to compress data before writing to tape.
(settable using appropriate 'mt setdensity <n>' - I was still looking for
the appropriate <n> when I found another way..)
This makes /dev/zero less than ideal a source of data to write to the
EOD, since it compresses, uh, VERY well! ;-)   I ended up just dumping
some random partition to tape instead.


Presto - I'm once again the lucky owner of the data I sought.

The ideal solution would have been the Exabyte "directory mode", but I
required a cable I couldn't get my hands on quickly.

Now, to think of a way to prevent this from happening again.  A qwerty
keyboard has 'F' right next to 'D' - typing 'mt eof' instead of 'mt eod'
is very easy.   I thought of patching mt not to allow eof, or to rename
the 'eof' to something else, but I fear I may break something else which
depends on this.  I think a better way would be to make a shell script or
alias such as 'eod-tape' which should be used when manually controlling
the tape drive, instead of mt.

A third possibility (I like this most so far) may be to write a wrapper
script for mt, which will ask for confirmation if you pass it the 'eof'
command, but only if it's running from an interactive tty, so
programs/scripts using it shouldn't be affected.   Comments?


Hope someone finds this info useful.

Regards

---------------------------------------------------------------|-----|--
Louis Mandelstam              Tel +27 83 227-0712   Symphony  /|\   /|\
Linux systems integration     http://sr.co.za       Research {   } {   }
Johannesburg, South Africa    mailto:louis@xxxxxxxx (Pty)Ltd {___} {___}