seek on raw magtape

[John Woods, Software]

> The major reason why tar is generally unwilling to add to a blocked tape
> is the inability to (portably!) seek the tape backwards to rewrite the
> last block of the previous contents. The major reason for this inability
> is that the "skip" primitives of tape systems...tend to work in blocks only.
> 
> Contemplating this, an idea came.  Given this uncooperative behavior of
> the hardware, the general seek-on-raw-magtape problem is intractable.
> But most tapes that one would be interested in seeking on, notably tar
> tapes, have a very simple structure. ...
> Specifically, on any tape one could seek to any block boundary within
> the region of tape already traversed by reads or writes, by having the
> driver remember the pattern of block sizes seen in those operations.
> 
> Can anyone see any holes in this?

To get useful behavior out of usual tapes, the magtape driver we use here has
the following feature:  when you open the tape drive, a blocksize-memory is
set to "not-yet-known".  The first read or write sets the blocksize-memory to
the blocksize which was read (not what you asked for, note).  If a future tape
block is of a different size, the blocksize-memory is set to "unknowable", and
seeks are ignored.  But as long as the entire tape is of consistent blocksize
(tar tapes, cpio, etc.) you win.

There is an ioctl primitive to pre-set the expected blocksize so that you can
do a seek before a read or write.

Remembering the exact pattern on the tape would be even more useful, but the
simple algorithm we use has (in my [the author's] humble opinion (:-) the
benefit of being very predictable -- and it would allow you to open the tape,
preset the blocksize, skip to the end of the tape, backspace one record, and
start writing -- without having to re-read the whole tape.


--
John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101
...!decvax!frog!john, ...!mit-eddie!jfw, jfw%mit-ccc at MIT-XX.ARPA

The Pentagon's Polygraphs:  Witchcraft for witchhunts.