PDA

View Full Version : QIC tapes: Skipping over files with errors - UNIX/CTIX & Linux



firebirdta84
March 14th, 2015, 12:22 AM
Progressing on now to reading some 25-30 year old QIC tapes (specifically DC600A, 9-tracks).

I'm able to read files right up until one experiences an error, but then I have trouble figuring out how to "jump over" that file, and try to read the next one (if that's even the right approach?)

I figured out how to tell the tape to move directly to the correct filemark, but it must still be doing error-checking along the way, because it gets hung up at the same place, and errors out, never reaching the filemark after the error.

I'm using
mt -f /dev/nst0 asf FileMarkNumber

I know that Al has done lots of readings of tapes of this vintage, and likely others here have as well, so I'm hoping to benefit from your experience on this.

Thanks again!
-AJ

bear
March 15th, 2015, 01:54 PM
It sounds like the linux tape device /dev/nst0 uses BSD semantics.

When a BSD-style tape device file is closed (i.e. dd exits after encountering a read error), the tape is left positioned at the end of the block that the read error occurred on. All that is required to continue reading the tape where the previous read left off (minus the block in error) is to open the tape device file again and start reading. It works the same way with positioning (mt fsf); mt ends when an error is encountered, causing the tape device to be closed. All you need to do is issue another 'mt fsf' to get to the next file mark (or keep doing it until you get a successful return code, in case of multiple errors). 'mt asf' may be more fragile in the event of encountering a tape error as I have seen some tape drive/tape driver combinations get confused/forget entirely about file position when encountering certain types of errors. You'll have to experiment.

This is NOT how a tape device with SysV semantics works. With SysV semantics, when the tape device is closed, the driver positions the tape to the beginning of the next file automatically (unless the tape is already on a filemark). So if the tape device gets closed after reading only part of a file (e.g. the program exits after encountering a read error), there is no way to get at any of the data between the error block and the end of the file.

Semantics don't matter if you have a program which doesn't close the tape device after encountering an error. The 'copytape' program may work this way; I'd have to check the source again. But dd and mt (as well as pretty much any other normal unix program for handling tapes) are both designed to exit on error, which causes the tape device file to be closed, and the driver semantics to matter.

firebirdta84
March 15th, 2015, 10:17 PM
Thanks for this, as well as your email, Bear. Much appreciated! I welcome more of your insight here, and I will continue to experiment and report back here.

-AJ

tingo
March 26th, 2015, 03:21 PM
FWIW, dd_rescue (http://www.garloff.de/kurt/linux/ddrescue/) (on a modern os) works wonders on hard drives with errors, I haven't tried it on tapes.