[lkml]   [1998]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: tapefs
    On Thu, 17 Sep 1998, Mark H. Wood wrote:

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

    Dick Johnson
    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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:44    [W:0.041 / U:10.260 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site