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

Pat Barron pat at transarc.com
Wed Sep 2 06:28:24 AEST 1998


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.



Received: (from major at localhost)
	by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id GAA02145
	for pups-liszt; Thu, 3 Sep 1998 06:45:08 +1000 (EST)


More information about the TUHS mailing list