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