Looking for rationale of fs naming conventions (more????)

Eric Fischer eric at fudge.uchicago.edu
Wed Sep 2 05:45:53 AEST 1998


> From: "User Rdkeys Robert D. Keys" <rdkeys at seedlab1.cropsci.ncsu.edu>

[snip]

> IF one is putting together a small system, where things like remote mounting
> or large numbers of users are NOT going to be present, are there any sorts
> of particular reasons to even have a /var fs?

There's no urgent need for it if you don't mind having it as part of
root or /usr.  On some systems it's nice to have /var on a separate
partition so that large mail spools or log files that fill up the /var
partition won't also break root or /usr, but this works both ways,
because if you had allowed it to be part of a larger partition it might
not have filled up in the first place.

> That leads to the question of whether or not it is workable to put
> var as a tree within the root fs?

Lots of systems set it up as just a regular directory within the
root directory.  Others (like SGIs) make it really be /usr/var
and put a symlink from /var to there.

> And, then, what did the earlier systems like 32V or V7 use as the
> mail or print spooling areas?

V7 mail keeps files in /usr/spool/mail; earlier systems did not have an
equivalent directory and delivered mail files directly to users' home
directories.  UUCP in v7 spooled files to /usr/spool/uucp.  The v6
manual (in the manpage for opr) refers to printer spool directories
/lib/dpr, /lib/lpr, and /lib/npr; the lpd manpage also lists /usr/lpd.

> I don't have much info on the earlier systems, except for bits and
> pieces that I have run across.  Sadly, our library here at MOO U,
> has little from earlier days.  Is any of this around on-line?

The v1 manual (as TIFF-format scans and OCRed PostScript), as well as
much other historical material, is available from Dennis Ritchie's web
page,

    http://plan9.bell-labs.com/who/dmr/

The v7 manual is also at the same site but in 

    http://plan9.bell-labs.com/7thEdMan/

The v6 manual can be extracted from the binary v6 distribution that you
can run on a PDP-11 emulator, though troff changed a bit between v6 and
v7 so you have to work a bit to get it to format with a modern ditroff.

> Does this imply that the permanent partitions were pdp-hardware related,
> or due to limitations in fs addressing schemes due to processor or
> code design limits?

I think they were specifically there for convenience.  The smaller
disks that were also supported did not all have partitions.

> Is the 2 and 3 partition ever used, or was that just something
> that came along for the ride with the hardware, and not used by 
> unix?

I imagine it would be used if you devoted an entire disk to a single
file system, or as a way of copying the entire contents of the disk
regardless of the partitioning to another device for backup.

> OK, now it is beginning to make some sense.  It would seem to be due
> to addressing limits in the machine (drive? processor? code?).

The v6 C compiler does not have long integers and the PDP-11 is a 16-bit
machine, so that's why everything was limited to 65536 blocks.  If you
want *real* weirdness, check out the v1 manual, in which the seek call
had not yet been made to deal with anything over 65536 *bytes*, so seeking
on disks worked very strangely.

> Interesting.  What sizes, relatively, were such drives from that era
> of the high-speed type, and by what manufacture?

If I'm reading the First Edition manual right, the fixed-head disk was
the DEC RF11, with 1024 256-byte blocks -- yes, 256K bytes for the
entire hard disk.  Dennis Ritchie's paper "The Evolution of the Unix
Time-sharing System" refers to a 512K disk, though, so I don't know
which to believe.

eric

Received: (from major at localhost)
	by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id GAA24981
	for pups-liszt; Wed, 2 Sep 1998 06:29:54 +1000 (EST)


More information about the TUHS mailing list