[conspire] fyi: Understanding the bin, sbin, usr/bin , usr/sbin split
rick at linuxmafia.com
Thu Feb 2 18:58:26 PST 2012
> 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)
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
More information about the conspire