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!henryjc@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
chris@umcp-cs.UUCP (Chris Torek) (01/07/86)
Of course, if you wanted to kludge up your Unix kernel, you could make the block tape device use large interrecord gaps, and then you could even make a file system on tape. (Did this once work? It does not in 4.[23]BSD.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
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.
john@frog.UUCP (John Woods, Software) (01/09/86)
> Of course, if you wanted to kludge up your Unix kernel, you could > make the block tape device use large interrecord gaps, and then you > could even make a file system on tape. (Did this once work? It > does not in 4.[23]BSD.) > -- This works quite well with normal interrecord gaps on both V7_and_2.8 (using 512 bytes per record) and 2.9 (using 1024 bytes per record). However, it give new meaning to the word SLOW... However, you have to mount the tape read-only. Even with large interrecord gaps, most tape drives aren't all that careful where they write a block, and the canonical behavior is for a repeatedly re-written block to slowly creep forward, eventually eating up all of that large interrecord gap (and the next block). DECtapes, on the other hand... -- 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.
laman@ncr-sd.UUCP (Mike Laman) (01/09/86)
In article <2704@umcp-cs.UUCP> chris@umcp-cs.UUCP (Chris Torek) writes: >Of course, if you wanted to kludge up your Unix kernel, you could >make the block tape device use large interrecord gaps, and then you >could even make a file system on tape. (Did this once work? It >does not in 4.[23]BSD.) If you put a file system on tape blocked with the same blocking factor internal to the kernel (so offset are happy), mount the tape as a READ ONLY file system, you could do it (/etc/mount /dev/mt/0 -r). I have done it myself. I thought it would be an amusing test to run after I finished writing a tape driver. It was amusing to see the system accessing various blocks on the file system. It certainly took a while to load a program since I had constructed the file system with a default rotational gap (via ``mkfs''). It was interesting to see the system access the superblock, inodes, directories and file blocks. I had the files a level down in the hierarchy so the system had to get the super block, root inode, root directory, subdirectory inode, subdirectory directory, file inode, file blocks. Seeing is believing. I'm afraid you lost me, Chris, about using large interrecord gaps. I don't see what it has to do with file systems on tape. I guess I got into the conversation too late. What is important is to get the tape driver's blocking factor and the system's internal block size in agreement, so filesystems offsets match with device driver offsets. This scheme should work for System V, System III, V7, and V6. I don't know enough about BSD systems to say. I would think it would work if the BSD kernel really doesn't update the superblock, but if the kernel does, your out of luck. The idea was suggested to me by Greg Noel. It seems he needed to access some data on a tape, but didn't have enough space on the disks, so he mounted the tape as a file system (pun intended) and left for the night. (He did this back in his V6 days about 6-8 years ago). Mike Laman, NCR, Rancho Bernardo UUCP: {ucbvax,philabs,sdcsla}!sdcsvax!ncr-sd!laman
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!henrybzs%bostonu.csnet@csnet-relay.arpa (Barry Shein) (01/10/86)
>From: Chris Torek <chris%umcp-cs.uucp@BRL.ARPA> >Of course, if you wanted to kludge up your Unix kernel, you could >make the block tape device use large interrecord gaps, and then you >could even make a file system on tape. (Did this once work? It >does not in 4.[23]BSD.) ^^^ From the SIXTH edition UPM (MOUNT(VIII)) "...the optional last arg [-r] indicates that the file is to be mounted read-only. Physically write-protected and magnetic tape file systems must be mounted this way or errors will occur when access times are updated..." Knew that would come in handy one day... -Barry Shein, Boston University
auerbach karl%b.mfenet@lll-mfe.arpa (01/10/86)
Way back when, some folks at UCLA used DECtape for the Unix swap
device. I heard that it actually ran!
(DECtape was a random-access tape unit that DEC once made for PDP-8
and PDP-11 machines. The tape was pre-formatted, much like disk packs.)
--karl-- (Karl Auerbach, Epilogue Technology Corp.)
Auerbach#K%MFE@LLL-MFE.ARPAcak@purdue.arpa (Christopher A. Kent) (01/10/86)
I did it, too, but for a while as production (until the sound of the tape drive drove me nuts.) This was on a pdp-11/60 with only 2 RK05s for disk, running research version 6; I had a copy of system sources and man pages on the tape. Thank goodness memory media have gotten a lot cheaper since then. And we've all found better toys to play with. Cheers, chris ----------
speck@cit-vlsi.arpa (Don Speck) (01/13/86)
A year ago I had to bring up 4.2bsd on two vaxen whose only
removable media were RL02's. My only way of writing an RL02 was
tape-to-disk copy on a VMS machine. So, I dd'd an appropriate
filesystem to a tape, and for paranoia, fsck'd the tape. Slow,
yes, but not much worse than the VMS machine was at copying to
the RL02.
When I tried to mount the tape as a filesystem, /etc/mount
refused, and then hung the tape drive - I got ENXIO on the next
open (probably the kernel forgot to close the device).
Don Speck speck@cit-{vax,vlsi}.arpahamilton@uiucuxc.CSO.UIUC.EDU (01/16/86)
>Thank goodness memory media have gotten a lot cheaper since then. And >we've all found better toys to play with. i recently read a product announcement for a new .25" casette tape storage system with a random-access feature. the more things change...