[ On Sun, January 3, 1999 at 15:41:47 (+0100), Havard.Eidnes@runit.sintef.no wrote: ]
> Subject: Re: Package Paths Proposal v2
>
> I think I remember seeing the announcement for the new hier(7) setup
> around when 4.3 was released, together with the rationale for the
> reorganization.  Not sure I still could find it, though.  If my memory
> serves me, the reasons for those parts of the proposal related to the
> root file system were mainly to:
> 
>   - reduce the rate of updates to the root file system so that a
>     crash is less likely to cause a broken and/or unrepairable root
>     file system
> 
>   - reduce the volume of the root file system to what's essential to
>     get the system back on it's feet again, and to reduce the volume
>     of what would be needed for an /altroot.
> 
> I think that going back to having a humungous root file system would
> negate both of these benefits, and I would argue against doing so.

Hier(7), which is normally quite explicit about where filesystem mount
points are highly recommended does *not* mention anywhere that /usr
should be a separate filesystem.  Maybe this is an oversight, but
without more authoritative documents very few among us can say for
certain.  As you've pointed out later in your message the separation of
/(root) and /usr has nothing at all to do with the reduction of daily
changes to either filesystem -- that's what creating /var did.  (Though
one might argue that /usr becomes the most stable and /(root) the second
most stable because /etc files are modified from time to time -- except
on a development system where /usr is less stable.)  (BTW, the need for
mounting /usr read-only has very little, if anything, to do with
making it more stable -- it's primarily so diskless workstations can
more safely, and more efficiently, share it.)

The following is from an i386 machine running -current.  /altroot hasn't
been updated since X11 was installed, which gives a very accurate
picture of just how silly it is to make an even tinier (eg. 16MB)
partition just for the stuff in a separate "root" partition.

11:55 [71] $ df -k
Filesystem           1K-blocks     Used    Avail Capacity  Mounted on
/dev/sd0a               490591   155321   310740    33%    /
/dev/sd0e               490591     9479   456582     2%    /var
/dev/sd1e               490591        1   466060     0%    /tmp
/dev/sd1a               490591    81121   384940    17%    /altroot

Another of the more subtle advantages of keeping the entire base OS in a
single filesystem becomes rampantly apparent to anyone who's been
frustrated by trying to repair a system with a dead /usr (because it's
on a separate spindle).  Sure we can all learn to get by on the bare
necessities, but when it only takes another 60-80 MB to get the benefits
of the entire suit of system utilities, why be frustrated?????

Unless you have a lot of old 10MB and 20MB disks lying around (that you
trust enough to actually use, and you have enough controller ports to
actually make use of them), there's no need to split the static files of
the base OS over multiple filesystems.

And of course if you are using multiple tiny and slow disks you'd
probably be better off merging them with CCD or now RAIDframe!  Even
without any of the above a simulation of merging can be effected with
union mounts.

>    SunOS 4 also
> needed to have /usr mounted to do system recovery if I remember
> correctly, whereas that didn't seem to be required on a system
> adhering to the 4.3 hier(7) setup.

I've managed to recover SunOS-4 systems with only the tools in /(root),
but it wasn't as easy as it could have been because mistakes were made
and most SunOS-4 distributions have some dynamic binaries in /sbin.


Anyway, unless someone forks off yet another *BSD it's unlikely that
full merging of /(root) and /usr will ever be anything more than an
academic discussion (at least in *BSD-land -- GNU Hurd and/or GNU/Linux
may be another story!).

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>