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>


> 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


The v7 manual is also at the same site but in 


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.


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