SCSI QIC Tape Woes

[Dave Olson]

In <BENEDICT.91May18121817 at chaos.utexas.edu> benedict at chaos.utexas.edu (Thomas Benedict) writes:

| Here's my problem:
| 
| We have a tape that has multiple tar format archives written to it.
| The way we did this was to skip to the end of tape, and then write an
| archive.  Simple 'nuff.  The problem is that the mt utility in IRIX
| seems to have a little glitch.  If you do an mt feom using
| /dev/nrtapens it will happily whirrrrr over to the end of tape, then
| happily rewind itself, then VERY happily tell you you are at the end
| of tape.

Are you absolutely, positively certain that you used nrtapens?  There
was a bug with this in 3.3 for Exabyte, but that was because the
sequence has to be emulated on Exabyte, and I missed a state in
a couple of sequences.  I have NEVER heard of this on the QIC
tapes (and believe me, if anyone had complained about it to SGI,
I would have heard it about it through many channels!)

| So our intrepid researcher skipped to the end (beginning) of tape and
| wrote his new backup, handily overwriting the beginning of his tape.
| He didn't overwrite a whole lot.  Maybe 20 meg tops.  So there's still
| around 80 meg of good data on the tape... only it's past the end of
| tape marker.

Sorry, but you are out of luck.  When writing from BOT, almost
all QIC drives erase all tracks ahead of the write head while
writing the first track (this includes the Archive drives that SGI
sells).  150 Mb / 18 tracks is just over 8 Mb per track, so the
whole tape was erased.


I realize it isn't much consolation, but one thing you learn
over time if you need your backups is to NEVER put more than
one backup per tape, if it isn't readily re-creatable, since
sooner or later you always make a mistake (or the vendor does
in their software).  True, this can waste a lot of tape, but
if you need it and you overwrote it, you didn't save any money.


If you have a reproducible (even if only occasionally reproducible)
case that shows your problem, I'd be very interested in the
details.  Scatter 'mt stat' through your script, hinv, and ls -l on
the devices will help in tracking down problems (yours or mine).


This is a standing invitation for SCSI tape and disk problems.

** NOTE **  this is NOT a substitute for the TAC (Technical
Assistance Center, formerly Hotline).  I have my job, they have
theirs, and mine isn't support.  I make no promises about fixing
problems, and I *NEVER, EVER* send patches, although I might
suggest a work around.  I WILL make an attempt to track down
*REAL*, *REPRODUCIBLE* problems, but I do ask that if you have
software support, start by using it; if not, consider buying
it.  I reserve the right to not reply immediately or even within a
reasonable time, due to the unreasonable demands of my managers
that I get my job done :)

The TAC has a long list of common problems and errors, and they are
more likely to spot and answer many of them than I am.  They also
need to know about the problem so that they can help the next
person who sees it.
--

	Dave Olson

Life would be so much easier if we could just look at the source code.