Date: Tue, 1 Sep 1998 16:28:24 -0400 (EDT)
From: Pat Barron <pat@transarc.com>
Reply-To: Pat Barron <pat@transarc.com>
To: "User Rdkeys Robert D. Keys" <rdkeys@seedlab1.cropsci.ncsu.edu>
cc: pups@minnie.cs.adfa.oz.au
Subject: Re: Looking for rationale of fs naming conventions (more????)
In-Reply-To: <199809011856.OAA15872@seedlab1.cropsci.ncsu.edu>
Message-ID: <Pine.GSO.3.96.980901155532.16237I-100000@smithfield.transarc.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-pups@minnie.cs.adfa.oz.au
Precedence: bulk

On Tue, 1 Sep 1998, User Rdkeys Robert D. Keys wrote:
> 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?

Sure, as long as you make the root filesystem large enough, you can just
have /var be part of the root filesystem (or do like small SunOS/Slowaris
systems do, and have /var be a symbolic link to /usr/var - reasonably
safe, since SunOS and Slowaris both tend to assume that /usr is always
mounted).

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

Mail is dropped into /usr/spool/mail, or /usr/mail, depending on what
system you're talking about.  Don't remember where printing went (I
actually don't remember if V7 even had a print-spooling system; I did a
lot of printing by doing "pr filename > /dev/lp"....

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

The partition sizes were compiled into the driver, not stored in a disk
label such as with more modern Unixes (and that was actually the case
until fairly recently - I don't think that disk labels made it into the
Berkeley code until at least the 4.3BSD-Tahoe release).  If you wanted to
change a partition boundary, you had to edit some constants in the driver
and recompile your kernel (or do what I used to do a lot - use "adb -w"
to change the driver tables on-the-fly, and then try to remember to make
the same changes to the source code so you didn't get a surprise next time
you rebuilt the kernel.....).

> >    This is done since the size of a full RP drive is 170,544 blocks
> >    and internally the system is only capable of addressing 65,536
> >    blocks.  Also since the disk is so large, this allows it to be
> >    broken up into more managable pieces.
> 
> OK, now it is beginning to make some sense.  It would seem to be due
> to addressing limits in the machine (drive? processor? code?).

This was a filesystem limitation; the filesystem code could not handle
more than 64K blocks in a filesystem, probably because it was using 16 bit
unsigned integers internally.

--Pat.