Re: Tape backup woes (mt)... should I file a bug report?
On Wed, 21 Apr 2004, Christian Schnobrich wrote:
> Eventually and accidentally, I found out about rewinding and
> non-rewinding device files, the information being hidden deep in the tar
> info file. For all who don't know it:
[ snip info about /dev/stX (auto-rewinding) vs. /dev/nst0 (non-rewinding)
tape devices ]
> I don't usually use info, and from the occasional man-vs-info flamewar
> on this list I know I'm not alone. Furthermore, I'd never have looked
> for this in the tar documentation. Or do I use tar to fast-forward the
> tape? All I knew to start with was that 'mt eom' apparently didn't work
> as advertised.
I agree, it is very non-intuitive. On the other hand, it is also in every
tape-backup FAQ I've ever seen, so the info is readily available. I'm not
saying that to be an asshole (really!). IMHO, the first steps to take when
something doesn't work right are to hit the man pages, followed by a
FAQ/How-To search. (See <http://tldp.org/>.) If you already know that,
then please ignore.
> IMO, the (non-)rewinding device issue should be mentioned in the mt
> manpage. But does this omission really justify a bug report? Or is it
> just me?
It's not a bug, so it probably shouldn't be approached as one. There is a
disturbing amount of voodoo involve in getting various scsi tape drives to
work in a sane fashion. The nst0/st0 device interface is the least of ones
worries.
FYI, not all tape drives will report their tape location (file status, byte
location, etc) in a consistent manner. My Archive Python DAT can get
confused following a sequence of fsf/bsf commands. The only reliable way
to count the number of files on a tape, and get to the one you want, is to
rewind to the beginning and then use either the afs or eom commands. Do
this before every operation where you are going to read/write to the tape.
This is kind of critical as it really sucks when you discover today's
incremental overwrote all of Thursdays and the first half of Fridays
because the backup script or tape hardware lost track of where it was.
Power cycles and computer reboots (ie. what happens when the scsi interface
is initialized) can also make the tape location indeterminate.
> While I'm at it, one more thing I don't understand -- mt comes with the
> cpio package, and there's another package mt-st one may install. I don't
> notice any significant difference between the two, so where's the point?
> Under what circumstances would I want or prefer mt-st over mt?
FWIW, I tried both the cpio-mt binary and the mt-st binary and ended up
sticking with the mt-st version. I have vague recollections that it seemed
to have more features...
--
Brad Sawatzky <bds9e@virginia.edu>
University of Virginia Physics Department
Ph: (434) 924-6580 Fax: (434) 924-7909
Reply to: