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.
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. :-)
-- Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu Speaking of DECtape, ask me about the DATE75 project.- 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/