write(2) to tape with odd byte count
Griff Smith
ggs at ulysses.UUCP
Mon Dec 9 03:04:39 AEST 1985
> Oh, boy! Magtape driver wars!
>
...
[deleted for brevity]
...
> I hope they fix the driver so it moves to the next tape mark when
> closed in non-rewind mode. It's great fun to get the tail of a
> file overwritten because of this misdesign feature.
I hope they don't! This feature of the System V drivers makes it
impossible to do serious tape hacking (besides, since when did UNIX
systems try to protect users from their own carelessness -) ). The real
flaw is with tar and cpio, both of which stop at end of data instead of
reading the tape mark that should immediately follow. When the "skip
to end of file on close" feature is implemented, the following things
can happen:
1. Suppose I have just gotten a large multi-file distribution tape
(the System V emulation package will do just fine). I have skipped
to the fourth file (which took 5 minutes on the toy 25ips streamer
I'm stuck with), then I want to verify that I am looking at the
right file. I enter "cpio -ictB < /dev/rmt/0mn", verify that the
right names are coming out, then hit break. Nothing happens; the
^%&$^&% operating system is skipping to the end of the file. I get
to wait another five minutes for it to find the tape mark, then a
third five minutes while I wait for the back space file to finish.
If the tape drive had stopped dead in its tracks, I would have
re-positioned it in about 15 seconds.
2. Worse, suppose I have just gotten 100 mbyte of critical data on a tape,
and block number 100 (out of 10000) is hopelessly munged. If I am
using one of the System V drivers, it will try to read the block a few
times (six, for the VAX TU78 driver), then return "fatal I/O error".
It also sets an internal flag that makes all subsequent attempts to
read fail. I am now stuck; I can't read any of the data after the bad
spot. If I close the tape file, the tape will be re-positioned. I
can't even skip over the bad data with "forward space record", since
System V doesn't have tape control operations. I might be able to put
the unit off line, close the file, then re-enable the drive, but don't
count on it. As a result of this "convenience" feature, I will have to
wait a week while a request for a new copy of the tape filters through
the bureaucracy.
I repeat, the flaws are in cpio and tar. These commands should read until
physical end of tape. If there is trash after the presumed end of file,
it should be detected and reported. Of course, it would also be nice if
the drivers would skip over bad blocks (after reporting the errors) and then
allow subsequent successful reads.
--
Griff Smith AT&T (Bell Laboratories), Murray Hill
Phone: (201) 582-7736
Internet: ggs at ulysses.uucp
UUCP: ulysses!ggs ( {allegra|ihnp4}!ulysses!ggs )
More information about the Comp.unix
mailing list