seek on raw magtape

[Mike Laman]

In article <2704 at umcp-cs.UUCP> chris at 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