> On Tue, 15 Sep 1998, Richard B. Johnson wrote:
> > A tape file-system by any name is just a program (read user-mode)
> > that puts directories for all the files on the tape SOMEWHERE.
> >
> > You can preallocate some blocks at the beginning for a directory
> > that contains directory information plus the starting offset tape
> > block,
>
> Actually the DECtape directory block was block 100 IIRC. The ends of the
> tape get beat up more readily than the middle, so you want the critical
> filesystem info. buried in the tape pack where it's a little safer.
> Anyway that's my guess as to why block 100. (Oops! was that 100 decimal
> or octal? :-)
>
> > or you can put directory information between the files
> > themselves. Both methods have been used by Digital.
>
> This approach simply adds system-specific information to the portions of
> standard ANSI tape label groups which are reserved for user
> specification. A handy thing it is, too, as long as you don't care how
> long it takes to open a file.
>
> > You can make
> > a RMS file-system on a tape and then "mount" it, or you can
> > mount a raw tape (called "foreign" in DEC lingo). Note that
> > `tar` creates a "file-system" on the tape so you can restore
> > individual files, etc.
>
> On VMS, tape files had not only names but ownership and protection masks
> as well. It worked pretty well when the tapes were kept behind the I/O
> window and you had to present yourself physically and sign out a tape in
> order to take it to another site and circumvent the protection.
> Nowadays, when one could just pick up the whole computer system and carry
> it off when nobody is looking, I guess that aspect is not so useful.
>
> > The problem is that a tape is a sequential device. You can't extend
> > a file, you can't delete a file (although you can pretend to by
> > marking its directory entry deleted).
>
> This is not true of DECtape, which has a separate timing track to mark
> fixed blocks and is formatted more like a disk. Files were threaded
> together with next-block pointers in each file block, and random access
> (either physically, or logically within files) was possible -- again
> assuming that you don't mind waiting. Nowadays this is a rather useless
> bit of knowledge since nobody makes drives like that anymore, but it
> *has* been done. The thing that made seeking on DECtape bearable was
> that the things were less than 600 blocks long.
>
> > The result is a write-once file-system with abysmal performance.
> > In the "olden" days, we had reel-to-reel tapes that could "seek".
> > These tapes could rapidly find "file-marks" so you could get some
> > random-access. The modern tape drives don't "remember" where they
> > are, so to count file-marks, you have to rewind and start from
> > the beginning. They are just not designed for random access.
>
> The driver could take care of maintaining the tapemark count, and as I
> recall it usually did. Where did you see drives that counted tapemarks
> in hardware? But I agree that tape drives are not designed for random
> access, at least not as the usual mode of use and not in the way we are
> accustomed to think of it.
>
The TU-77 reel-to-reel counted tape-marks in hardware. This created a
problem when you first physically mounted a brand-new tape. It would zip
back and forth on its own, trying to find out where it was. If there were
no file-marks, it would report "position-lost" which would confuse
'MOUNT'. Eventually MOUNT was 'taught' to ignore same.
> More DECtape trivia: the seek code would compare current position to
> desired position, start the correct hub motor, calculate how long it
> would take to get fairly near the desired block, and set a timer. When
> awakened it would ask the drive which block had last gone by and do the
> right thing. Tape speed was nearly constant since the tiny reels weighed
> only a few ounces, so the calculation was pretty simple.
>
> [Interesting idea for a RAMdisk with tape as backing store omitted]
>
> One of the things I really miss in the Unix world is labelled tapes. Tape
> volumes are not so cheap that I'm not sorely tempted to put multiple files
> on a tape, but then I have to keep my own manual records of which one is
> which and I know what would happen *then*. :-/ Having named files on tape
> was so nice that I've often toyed with the idea of writing a driver that
> would take over a physical tape drive and add ANSI file/label semantics
> (but to date I haven't gone so far as to code anything). I know it'd be
> slow, but us old fogeys *knew* tape was slow and used it appropriately.
> Usually most of the delay in tape storage/retrieval was caused by the
> operators, not the transport. :-)
>
Yes, Yes. The good old days, but those who forget the past are likely
to repeat its failures.
> --
> Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
> Speaking of DECtape, ask me about the DATE75 project.
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.1.118 on an i586 machine (66.15 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/