[TUHS] Determining what was on a tape back in the day

[pechter@gmail.com (William Pechter)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]

Dave Horsfall wrote:
> On Mon, 20 Nov 2017, Random832 wrote:
>
>> For whatever it's worth, the tm(4) and ht(4) manpages from V5 onward
>> say "seeks have their usual meaning", and both drivers provide a
>> 'non-raw' device which is a block device and (according to the
>> manual) only supports tapes consisting of 512-byte records - the BUGS
>> section mentions that the raw device, conversely, does *not* support
>> seeking.
>
> Thank you; I dimly recall that seeks were implemented by the driver
> keeping track of whichever block was under the head, and skipping
> forwards or backwards accordingly, with simple arithmetic. I no longer
> have access to those sources, but we at UNSW certainly modified Unix
> rather heavily, so if that capability is not in the distributed
> version then it means that we modified it; this was over 30 years ago...
>
> It bloody well worked as a read-only file system; I take great umbrage
> at the implication that I am a liar, and I'm the sort of obstreperous
> bastard who neither forgives not forgets...
>
I know that a read-only filesystem for installs is possible.  Pyramid
Technologies used a tape install filesystem called ROFS...guess what
that stands for...

We used it on both cartridge (QIC-150 iirc) and 9 track magtapes... So
there's no special type of drive needed.
It was created by dd-ing  a chrooted specially constructed file tree
(IIRC).   I constructed special ones at my
site with all the site specific info (passwords, groups, etc) on it for
emergency recovery.

It was used for their OS/x (BSD-SysV dual universe for their Risc CPU)
and DCOSx (SVR4 port to Mips R3000).

Bill