Subject: Re: /etc/rc.d/ runs slowsly
To: NetBSD-current Discussion List <>
From: Greg A. Woods <>
List: current-users
Date: 04/12/2000 16:52:32
[ On Wednesday, April 12, 2000 at 09:05:34 (+1000), Robert Elz wrote: ]
> Subject: Re: /etc/rc.d/ runs slowsly 
> I prefer to keep / small (and as stable as possible too) not because I
> can't find a drive big enough to hold both it and /usr, but because I
> prefer to replicate it widely (on every drive I can boot from, at least
> until I have more copies than I can manage).   For that, on systems I
> really care about, I have / mirrored, so there is always an up to date
> copy of it on another drive (on another controller), and then I also
> have a couple of increasingly less frequently updated copies, so I always
> have a root that was known to be workable, sometime in the past (mirrors
> don't help when someone installs a broken init, or does rm -rf /).

True enough.  I would continue to argue though that a root filesystem is
still small enough (and on *BSD certainly stable enough) to do this
with.  In fact I do exactly this with /altroot on quite a number of
production systems I run....  On an Intel x86 box it's still only 220MB,
even with X11 and the compilers installed.  On most of my systems a full
copy of that to another disk only takes a couple of minutes at most.

> For backup of /usr a CD is a wonderful choice - nothing on /usr needs to
> be writeable in ordinary use (only for installing new versions), CD blanks
> are real cheap, and they aren't susceptible to be overwritten by something
> more immediately useful...   Putting / on a CD is a much less useful choice,
> unwriteable root partitions (while useful for minimal tasks) are much harder
> to deal with.

Though I've only done it once myself I recommend this to many people
too, but again still with /usr on the root filesystem.  The files that
are mutable on the root filesystem are easily backed up on a floppy,
usually even a 360KB floppy if compressed.  In some cases it pays to
burn a new recover CD for every change anyway (eg. a production web
server, etc. where all the important data is effectively static).

> For this to succeed, the space used needs to be small - again, not because
> the cost ($ terms) would be too huge to keep four or five copies around,
> but because when someone sees most of the filesystems full, and they need
> some extra space to do some work in a hurry, a 200-500 MB (whatever it takes)
> space that isn't mounted, and doesn't look to being actively used for
> anything is a very tempting target.   A 25Mb partition (which is what I
> like / to be) isn't usually very interesting or useful - it is usually
> possible to recover that much by just finding a few core files and nuking
> them (or some .o's or netscape caches, or ...)

That's easy to solve:  always mount your /altroot* partitions read-only
(except of course during the time you update them).  If that's not quite
enough then put a big comment in /etc/fstab, as well as in
/altroot/README.FIRST, to document what's up and to sufficiently
threaten any would-be abusers of such backups.

> In any case, you're free to keep combining /usr and / in one partition if
> that suits you, as is anyone else - but I suspect that we've all become
> rather tired of hearing that it is the way things ought to be done.

What I'm *REALLY* tired of are those who say that it must not be done!  :-)

It's one thing to point out reasons why one might want the root
filesystem to be small but quite another to say that there must be a
split without understanding the reasons why it should or should not be so.

							Greg A. Woods

+1 416 218-0098      VE3TCP      <>      <robohack!woods>
Planix, Inc. <>; Secrets of the Weird <>