Stacked dump tapes

[Guy Harris]

> 1) Does anyone have any caveats or horror stories about using multiple
>    partition dumps to multiple files on a single tape?

One rather nasty horror story; the "dump" program determines the location of
the end of the tape by dead reckoning.  You tell it how long the tape is,
and it counts blocks and stops when it *thinks* it's at the end.

Not only is this a bit of a problem if you get tape errors (because most
drives/drivers do a "write with extended interrecord gap" operation to skip
the bad spot; this means not all the blocks on the tape are as long as "dump"
thinks they are), but it really fouls up dumping multiple partitions to
multiple files.  The first dump doesn't have any trouble, but to have the
second dump work you'd have to tell "dump" how long the remaining part of
the tape was, etc..

The OS's handling of the end-of-tape condition (note - *not* error) should
possibly be changed, and "dump" should be changed to use the end-of-tape
indication to tell it when to change tapes.  The DEC RSX-11 family OSes
(including VMS) treat end of tape as a special condition, not an error;
unfortunately, for UNIX to do this you would either have to use a new system
call rather than "write" or have an "ioctl" call to test the EOT status
and do that "ioctl" after *every* write.

Given the RSX-11M (and probably many many other OSes) way of handling EOT, ANSI
standard tapes deal with EOT by writing volume trailer records after the block
that got the EOT condition.  The tape foil should be placed (and usually is
placed) sufficiently before the physical end of tape so that there is enough
room to write the trailer labels.  One does run the risk here of spinning
the tape off the end of the reel, as the OS permits you to do this in order
to let you write or read the trailer labels.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy