[net.periphs] seek on raw magtape

henry@utzoo.UUCP (Henry Spencer) (01/05/86)

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 seldom let you specify a
skip in bytes, or tell you how many bytes they have skipped -- they 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.  They usually have at most two block
sizes, a main size plus perhaps a shorter one for the last block.  On a
tape like this, limited seeks are possible even with the usual hardware.
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.
And on the usual tapes, the pattern is very simple.  The storage and
bookkeeping effort needed to remember it would be small.  Probably best
would be to remember the pattern since the last tape mark, which would
let one use seeks within one file on a multi-file tape.

Can anyone see any holes in this?
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry

jc@sdcsvax.UUCP (John Cornelius) (01/06/86)

The reason you cannot randomly access tapes for writing is because if an error
occurs while writing, the procedure is to erase 3 inches of tape. Assume that
you had written 3 records of directory. If, while trying to rewrite the middle
one, an error occurs the system will back up over it, erase 3 inches of tape,
and attempt to rewrite the record. This would clobber the 3rd record and
perhaps several others as well since the standard gap between records is only
1/2".

A related issue is the location of the erase head on a tape drive. When writing
tape the drive erases tape ahead of the writing head. The erase head can be as
much as an inch ahead of the write head. This too can clobber the next record.

John Cornelius
Western Scientific

john@frog.UUCP (John Woods, Software) (01/09/86)

> 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@MIT-XX.ARPA

The Pentagon's Polygraphs:  Witchcraft for witchhunts.

henry@utzoo.UUCP (Henry Spencer) (01/10/86)

> The reason you cannot randomly access tapes for writing...

Who said anything about randomly accessing tapes for writing?  If you
study my initial posting, you'll see that what I want is to read some,
back up slightly, and then start writing from there.  No random-access
writes are involved.

Random-access writes are indeed impossible unless you're really confident
about media integrity.  (It's been done, at low densities with good tapes,
but I wouldn't try it at 6250!)  Random seeking followed by sequential
writing isn't the same thing.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry