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 <[EMAIL PROTECTED]> University of Virginia Physics Department Ph: (434) 924-6580 Fax: (434) 924-7909 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
