Oh yeah, I forgot that:  With a rw /usr, crashes can be more
dangerous and fsck takes a while.  fsck on a 50MB partition
and a /home will take far less time.

And on the dev system, when I'm trying something risky
(like a wierdo dangerous device driver), I'll make
*everything* readonly for the boot (or the kernel module
load).

When (not if:) it crashes, no lost+found, no fsck.


Null mounts have some baggage - 1) they've been a little
iffy at times and 2) they can confuse the hell out of people.

ls -l /var/tmp  showing a link to /mfs/var.tmp/  is pretty clear.

or 6 of one, 1/4 of 2 dozen of another...

Quoting Andrew Brown (atatat@atatdot.net):
> >>    Well, in systems used by groups of people (ie. not at home), /usr
> >> and /usr/local (oft the same) grow and this gets replaced and someone
> >> needs that and put it in and, oh where did the space go?
> >
> >Thats why I like having one big partition. On a 120G drive, I don't
> >like deciding /usr/pkg needs N gigs and /home needs M gigs etc. I just
> >make it one big partition and I rarely have trouble. I used to spend
> >lots of time symlinking crud back and forth because of space
> >misallocations -- it no longer happens...
> 
> you don't need to waste time and energy on symlinks...
> 
> ...you can use null mounts (with the hidden option to make the df
> output stay nice) if you need to move space around.
> 
> the one big filesystem thing *blows chunks* if you need repeatedly to
> crash a machine (or if a machine is repeatedly crashing) in search of
> a kernel bug.  with multiple filesystems, you can choose not to mount
> or to mount ro some larger ones, so that the fsck time on reboot is
> shorter.