Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 beta 3/9/83; site frog.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!cybvax0!frog!john From: john@frog.UUCP (John Woods, Software) Newsgroups: net.unix-wizards,net.periphs Subject: Re: seek on raw magtape Message-ID: <315@frog.UUCP> Date: Thu, 9-Jan-86 11:16:54 EST Article-I.D.: frog.315 Posted: Thu Jan 9 11:16:54 1986 Date-Received: Sat, 11-Jan-86 07:16:40 EST References: <6267@utzoo.UUCP> Organization: Charles River Data Systems, Framingham MA Lines: 38 Xref: watmath net.unix-wizards:16344 net.periphs:964 > 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.