Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.uwa.edu.au!classic.iinet.com.au!news.uoknor.edu!news.ecn.uoknor.edu!qns3.qns.com!news.sprintlink.net!gatech!swrinde!elroy.jpl.nasa.gov!ames!onramp.arc.nasa.gov!viking.arc.nasa.gov!lamaster
From: lamaster@viking.arc.nasa.gov (Hugh LaMaster)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Stability: FreeBSD, NetBSD, or Linux ?
Date: 18 May 1995 22:36:30 GMT
Organization: NASA Ames Research Center
Lines: 113
Distribution: world
Message-ID: <3pgi5e$j5a@onramp.arc.nasa.gov>
References: <ortegaD7puFE.Dp2@netcom.com> <3o6gj4$e1m@agate.berkeley.edu> <3o84ia$fa6@newshost.lanl.gov> <1995May3.185147.4535@mdl.sandia.gov> <3oe4sk$m41@nova.netapp.com>
NNTP-Posting-Host: viking.arc.nasa.gov
In article <3oe4sk$m41@nova.netapp.com>,
guy@netapp.com (Guy Harris) writes:
|> Alan F Lundin <aflundi@sandia.gov> wrote:
|> >This goes back a number of years I believe (about 6 or
|> >7 years?). The story, as I remember, was that Sun, Dec,
|> >CSRG (and perhaps others) got together to restructure
Sun, DEC, and CSRG were working on it in 1988 for sure.
|> >the filesystem to support networking, diskless workstations,
|> >and heterogeneous platforms better.
|>
|> Yup.
|>
|> It was originally done by Sun, as part of SunOS 4.0, in order to, among
|> other things, better support diskless machines.
Most of the changes were supposed to go into Ultrix 2.4, SunOS 4.x,
and were supposed to go into 4.4 BSD [insert history of 4.4/CSRG here].
Most of the changes were very rational.
The goal was to have as
|> little as possible in the root file system that would be likely to be
|> shared by multiple diskless clients of a single server, and *nothing* in
|> the "/usr" file system that couldn't be shared by diskless clients of a
|> single server, assuming those clients had compatible architectures and
|> ran the same OS release.
That is right. /usr is supposed to be NFS-mountable, read-only.
|> I forget precisely why "/var" was split off,
Per-machine variable directories, including mail, spool,
acct/adm, log, crash, and /var/tmp, which is to replace
/usr/tmp. /usr is supposed to be (potentially) read-only,
so anything in /usr which isn't goes in /var.
but I suspect it was to
|> keep small stuff like configuration files in one place (typically
|> "/etc") and big stuff like log files and spool directories in another
|> place. (As I remember, within Sun there was some shuffling of stuff
|> between "/etc" and "/var" before the final file system layout was
|> chosen.)
/etc was also per-machine, but for config files. Should be small.
|> You probably want whatever file system contains "/var" to be large;
|> SunOS 4.x (and probably some other OSes) come with a small root
|> partition, which is unfortunate as "/var" is, by default, on the root
|> partition in 4.x. At Auspex, we put "/var" on its own partition; I'd
|> done that on some machines I used at Sun.
/var was intended to be on its own partition I'm sure,
or possibly even a number of partitions as necessary on
large servers.
|> "/usr/share" was, as you note, intended for stuff that could even be
|> shared by clients with *incompatible* architectures, e.g. most text
|> files (other than configuration files that might be changed on some
|> particular host), and binary files in a machine-independent format.
I think /usr/share may have been a later change. Originally this
was called /usr/text. But yes, it was intended to be architecture-
independent, and residing on a common (group) server.
|> The Sun folks then got, as I remember, DEC and CSRG, and perhaps others
|> - precisely as you note - to get them to pick up on it as well. I
|> forget whether AT&T was in that group at the time, or whether they
|> picked it up later as part of the Sun/AT&T SVR4 deal.
|>
|> The scheme that most vendors seem to be offering differs from the SunOS
|> 4.x scheme in one fashion - the SunOS 4.x scheme puts binaries expected
|> to be used primarily by a system administrator or by an "/etc/rc"-type
|> file, and binaries for daemons and the like, in "/usr/etc", while the
|> scheme used by later BSDs and by SVR4 (and thus by SunOS 5.x) puts them
|> in "/usr/sbin".
/sbin was intended for root binaries only, while /etc was
intended for config files. /bin was supposed to be minimal
bootup binaries (e.g. sh). But /usr/sbin and /usr/etc were
going to be a single directory, since /usr is supposed to be
global/NFS-mountable/read-only. There is certainly room for
taste here, but consistency would be nice... I'm not sure
I ever understood /bin, /sbin, /usr/bin, /usr/sbin exactly.
|> Also, Berkeley wasn't as aggressive about keeping "/sbin" as small as
|> possible as was Sun. "/sbin" is on the root file system, and wouldn't
|> be shared by diskless clients; Sun put in there, in 4.0, *only* those
|> programs necessary to get "/usr" mounted - as the machine might be a
|> diskless client, this includes some networking stuff, and also includes
|> a shell because the stuff necessary to get "/usr" mounted gets run from
|> one of the "/etc/rc*" scripts ("/etc/rc.boot" in SunOS 4.x).
|>
|> Sun did, of course, leave a pile of symlinks around, for the benefit of
|> old programs and old programmers. :-) For example, old binaries might
|> looked for the "termcap" file in "/etc", so, even though the "termcap"
|> file belongs under "/usr/share" in the new scheme, a symlink was left to
|> it in "/etc".
I still mostly like this SunOS 4.x/CSRG organization better than
some other variants, which still often assume, one way or another,
that a {file,boot} server is only serving one architecture type,
something which has virtually never been true in my experience.
If you can't mount a shared readonly /usr from a server with
a different architecture, there is something wrong.
--
Hugh LaMaster, M/S 233-9, UUCP: ames!lamaster
NASA Ames Research Center Internet: lamaster@ames.arc.nasa.gov
Moffett Field, CA 94035-1000 Or: lamaster@george.arc.nasa.gov
Phone: 415/604-1056 #include <std_disclaimer.h>