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

[User Rdkeys Robert D. Keys]

> > From: "User Rdkeys Robert D. Keys" <rdkeys at seedlab1.cropsci.ncsu.edu>
> > Why the differences between 4.3 and 4.4 as relates to var?
> 
> I believe /var originated in SunOS at a time when Sun was heavily
> promoting network-mounted file systems.  In order to allow /usr to be
> mounted read-only across the network from a shared server, it was
> necessary to move all the files that would need to be modified by a
> running system from their traditional locations in /usr onto a file
> system that would be writable (and probably not shared with other
> systems).  The rearrangement was then widely copied by other systems,
> including 4.4BSD.

OK.  Now it is beginning to make sense.

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?  For example, on my FBSD
boxes (yeah, I know new stuff and not Ancient Unixes, but I have to run
it at the office --- at home is another story), I find that I use var
mostly for temp stuff, spooling prints and mail, and little else.
The ftp user is off on another fs with regular users, where space is
not critical (since my ftp archives can vary widely, across time) and
I don't want to take up a lot of space with a mostly empty var.
That leads to the question of whether or not it is workable to put
var as a tree within the root fs?  And, then, what did the earlier
systems like 32V or V7 use as the mail or print spooling areas?
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?

> > Why the convention of hd0a/b/c/d/e/f/g/h for the various fs?  I understand
> > the reasoning of a/b/c, but after that the rhyme and reason goes wild,
> > with everyone seemingly doing their own thing.  What was the logic of it,
> > originally?
> 
> It looks like this one really originated with the Seventh Edition,
> where "hp" disks were permanently partitioned as follows:
> 
>     partition  start   length
>        0       0       23        -> a
>        1       23      21        -> b
>        2       0       0         -> c
>        3       0       0         -> d
>        4       44      386       -> e
>        5       430     385       -> f
>        6       44      367       -> g
>        7       44      771       -> h
> 
> (the start and length are in cylinders of 418 blocks apiece)

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?
 
> A generic installation, according to the manual, would put root on
> partition 0, swap on partition 1, and /usr on partition 4 or 7.
> Partitions 2 or 3 could be used to access an entire disk.

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?

> Clearly if partition 4 was used for /usr then partition 5 could be used
> for something else, while if 7 was used it would take up the entire
> rest of the disk.  I'm not sure what the motivation was for the size of
> partition 6, even though partition g now seems to be the standard one
> for /usr, but presumably the space between cylinders 411 and 430 could
> be put to use somehow.
> 
> The Sixth Edition also had fixed-size partitions, but of different
> sizes than the Seventh Edition used:
> 
>     partition  start   length
>        0       0       9614      -> a
>        1       18392   65535     -> b
>        2       48018   65535     -> c
>        3       149644  20900     -> d
>        4       0       40600     -> e
>        5       41800   40600     -> f
>        6       83600   40600     -> g
>        7       125400  40600     -> h
> 
> (these numbers are in blocks, not cylinders).  The manual explains
> the motivation for partitioning:
> 
>    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?).

It is interesting that here it seems that partitions 1 and 2 were
co-addressed, or overlapping, while 4/5/6/7 were sequentially laid
out across the disk, perhaps.  It would seem that 4/5/6/7 were just
simple divisions of the disk into 4 pieces.  Was something like this
done to accommodate whether the drive was used a a boot drive or
a secondary drive?

> I don't understand why these particular sizes were chosen, though,
> because they don't seem to add up in any sensible way without wasting
> space or overlapping.
> 
> > Why the sizes of the various fs?
> 
> The original reason for root to be small and /usr to be large was, I
> believe, so that the most commonly-used files could be kept on a small,
> fast, and expensive, head-per-track disk, while the less-frequently used
> files would be on the larger, slower, but cheaper conventional disk,
> and the division was maintained even when systems put both file systems
> on the same disk.  As for the exact sizes chosen, I don't know.

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

> eric

Again... Thanks!

Bob Keys


Received: (from major at localhost)
	by minnie.cs.adfa.oz.au (8.8.8/8.8.8) id FAA24871
	for pups-liszt; Wed, 2 Sep 1998 05:46:21 +1000 (EST)