Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 15 May 1998 11:29:58 +0930
From:      Greg Lehey <grog@lemis.com>
To:        MIKE JENKINS <jenkins.mike@epamail.epa.gov>
Cc:        freebsd-questions@FreeBSD.ORG
Subject:   Re: Multiple partitions per disk (was: Writable /usr?)
Message-ID:  <19980515112958.E305@freebie.lemis.com>
In-Reply-To: <s5586c31.050@wpmail.gbr.epa.gov>; from MIKE JENKINS on Tue, May 12, 1998 at 03:34:08PM -0500
References:  <s5586c31.050@wpmail.gbr.epa.gov>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 12 May 1998 at 15:34:08 -0500, MIKE JENKINS wrote:
> Greg,
>
> I think "we are mixing apples and oranges".  The multiple partitions
> I am talking about are the OS partitions not the user partitions (/home).
> I agree that a single partition per disk for non-OS stuff is a good idea.
>
> The question is "How do you set up the OS partitions for installation?".
> By default, a 4.4BSD install wants a /, swap, /var, and /usr and this is
> spelled out in "Installing and Operating 4.4BSD UNIX". You could minimize
> this and have a /, swap, and /usr (like SunOS 4.X) where /var lives in /
> (or symlink /var to /usr/var after the install).  You could also minimize
> this and have a / and swap where /var and /usr live in /.
>
> I like a small /, a MFS /tmp, a separate /var, and a read-only /usr.
> If I want to build the OS, I'll use a separate /usr/src filesystem.
> You like a small / and a large /usr for the rest of the OS.

Well, I don't think we're shooting past each other.  We just differ in
our opinions.

Your method (which, as you demonstrate, many share) would work well if
you knew the sizes of the system partitions in advance.  But that's
not normally possible.

Let's look at the guidelines in more detail:

> The  filesystem  in 4.4BSD has been reorganized in an effort
> to meet several goals:
> 1)   The root filesystem should be small.
> 2)   There should be a per-architecture  centrally-shareable
>      read-only /usr filesystem.

Now this is new to me.  I don't necessarily disagree with read-only
/usr, but sharing it implies a faster NFS implementation than we have.

> 3)   Variable per-machine directories should be concentrated
>      below a single mount point named /var.

OK.

> 4)   Site-wide  machine  independent  shareable  text  files
>      should  be  separated from architecture specific binary
>      files and should be concentrated below a  single  mount
>      point named /usr/share.

I have a basic problem with mounting on a non-root file system, but it
looks like I'm outvoted on this one.  Apart from that, note that this
is a gratuitous additional partition.  Once upon a time this was
necessary for NFS mounts, but this is no longer the case.

> These goals are realized with the following general layouts.
> The reorganized root filesystem has the  following  directo-
> ries:
>
> /etc     (config files)
> /bin     (user binaries needed when single-user)
> /sbin    (root binaries needed when single-user)
> /local   (locally added binaries used only by this machine)

I've never seen this.   I suppose it's OK.

> /tmp     (mount point for memory based filesystem)
> /dev     (local devices)
> /home    (mount point for AMD)
> /var     (mount point for per-machine variable directories)
> /usr     (mount point for multiuser binaries and files)
>
> The  reorganized  /usr filesystem has the following directo-
> ries:
>
> /usr/bin       (user binaries)
> /usr/contrib   (software contributed to 4.4BSD)
> /usr/games     (binaries for games, score files in /var)
> /usr/include   (standard include files)
> /usr/lib       (lib*.a from old /usr/lib)
> /usr/libdata   (databases from old /usr/lib)
> /usr/libexec   (executables from old /usr/lib)
> /usr/local     (locally added binaries used site-wide)

Note this one.

> /usr/old       (deprecated binaries)
> /usr/sbin      (root binaries)
> /usr/share     (mount point for site-wide shared text)
> /usr/src       (mount point for sources)
>
> The reorganized  /usr/share  filesystem  has  the  following
> directories:
>
> /usr/share/calendar     (various useful calendar files)
> /usr/share/dict         (dictionaries)
> /usr/share/doc          (4.4BSD manual sources)
> /usr/share/games        (games text files)
> /usr/share/groff_font   (groff font information)
> /usr/share/man          (typeset manual pages)
> /usr/share/misc         (dumping ground for random text files)
> /usr/share/mk           (templates for 4.4BSD makefiles)
> /usr/share/skel         (template user home directory files)
> /usr/share/tmac         (various groff macro packages)
> /usr/share/zoneinfo     (information on time zones)
>
> The  reorganized  /var filesystem has the following directo-
> ries:

No problems with /var.

The big problem is /usr/local.  You have two choices:

1.  Mount it as a separate file system.  See my comments above. It
    also doesn't help manage space any better.

2.  Put it on /usr.  This makes it difficult to install ports (/usr is
    read-only), and it makes it impossible to determine in advance how
    big /usr is going to be (most ports install into /usr/local).

About the only thing in favour of this scheme is that it allows a
read-only /usr with some restrictions.  So does including /usr in the
root file system.  You could achieve all this on a reasonably large
disk (1 GB) with two partitions: the root partition, including those
parts of /usr which are not intended to be separate file systems, and
/<mumble> (maybe /var), which could include /usr/local and /usr/share.

Greg
--
See complete headers for address and phone numbers
finger grog@lemis.com for PGP public key

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980515112958.E305>