[conspire] fyi: Understanding the bin, sbin, usr/bin , usr/sbin split

[Rick Moen]

I wrote:

> The ability to boot a minimal standalone system without successfully
> mounting /usr and ability to do repair, maintenance, backup, and restore
> from a small filesystem furnishing /bin, /sbin, and /lib is _not_ an
> artifact of small hard drives.  It was routine caution against likely
> failure modes involving the contents of /usr, providing a method to
> recover from them.

Nor is that the only reason why people sometimes elect to have /usr
separate.  There are a number of other reasons, and frankly Rob Landley 
really ought to know better.  If I seem a little peevish about this
entire topic, it's because I recognise the distinctive odour of
freedesktop.org bullshit:  They never learn, and there's no point
talking to them.

Anyway, the server that hosts this mailing list has:

<System> <mount point>          <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
/dev/sda7       /               ext3    defaults,errors=remount-ro 0       1
/dev/md3        /home           ext3    defaults        0       2
/dev/sda8       /recovery       ext3    noauto          0       2
/dev/sda9       /usr            ext2    nodev,ro        0       2
/dev/md4        /usr/local      ext3    defaults        0       2
/dev/sda6       /var            ext2    noatime,nodev,nosuid 0       2
/dev/md1        /var/lib        ext3    nodev           0       2
/dev/md2        /var/spool      ext3    defaults        0       2
/dev/md0        /var/www        ext3    nodev,nosuid    0       2
/dev/sda5       none            swap    sw              0       0
/dev/sdb8       none            swap    sw              0       0
/dev/sdc8       none            swap    sw              0       0

Notice that the /usr filesystem is (1) ext2 (unjournaled) and (2) normally 
read-only [RM:  originally posted to say 'unmounted' in a moment of 
over-hasty writing; correcting in the archives to avert reader confusion].  
What's that all about?

Having /usr normally read-only [RM:  originally posted to say 'unmounted']
is another example of 'routine caution against likely failure modes'.  
That filesystem is where almost all system programs and libs live, and 
on a typical Linux system is (at least by default and initially) where 
most of its complexity and disk usage is.  It is a tree you as local 
system administrator wish to protect against mishap.  The most likely 
source of such mishap is: you, the local system administrator.

I have /usr normally read-only [RM:  originally posted to say 'unmounted'] 
in order to have in place a first-level default protection against the 
worst threat to its orderly management and contents, i.e., against myself.  
If I am careless with the root-user account and launch a recursive chown 
of something that would cascade down /usr, for example, it will (by design) 
fail.

Pretty much the only time /usr needs to be mounted read-write is during
package operations.  For that exact reason, I have a pair of scripts 
invoked via dpkg hooks that remount /usr read-write just before packages
get installed or removed, and then remount it read-only again
immediately when the package operations are done.

Note that I carve /usr/local, the only part of /usr that isn't normally
static in the way I describe, as a separate filesystem -- so that /usr 
is free to be treated as static other than during package operations.

Rob Landley and his friends at freedesktop.org?  I'm sure the thought of
this functionality never even occurred to them.   They've thought no
further than their own party line that 'separate /usr has been broken
for years', and the idea of consulting actual system administrators
about their professional concerns before screwing around with
filesystems is the very furthest thought from their minds.

Why is /usr an ext2 filesystem?  Because, since it's mounted read-only
99.999% of the time and only briefly made read-write for a few seconds
while adding or removing packages, the overhead of journaling would be
wasted.  So, Don't Do That, Then.

The /var filesystem is ext2 (and has the noatime mount option) for
maximum performance, having had all subtrees of ongoing significance
(/var/lib, /var/spool, /var/www) carved out separately.

I expect the freedesktop.org people likewise cannot understand the
motivation of custom mount flags and filesystem choice for performance,
either -- nor strategic ordering of filesystems around the swap partitions
in order to minimise average seek distance, improved disk speed, and 
longer disk service before failure.  There seem to be a whole lot of 
aspects of competent system operation that they class as 'obsolete' and
'what people used to do when they had small hard disks'.

And, just by coincidence, freedesktop.org / GNOME stuff apparently
breaks unless everything's on One Big Dumb Partition.  Gosh, who'd have
thought?