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
Subject: Re: seek on raw magtape
Message-ID: <316@frog.UUCP>
Date: Thu, 9-Jan-86 11:25:03 EST
Article-I.D.: frog.316
Posted: Thu Jan  9 11:25:03 1986
Date-Received: Sat, 11-Jan-86 07:16:57 EST
References: <6267@utzoo.UUCP> <1277@sdcsvax.UUCP> <2704@umcp-cs.UUCP>
Distribution: net
Organization: Charles River Data Systems, Framingham MA
Lines: 23

> 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.