Public SourceMage Discussion List

[flux <flux AT sourcemage.org>]

David Kowis (dkowis AT shlrm.org) wrote [12.02.08 01:31]:
> The article covers the most common use cases for a network mounted or a
> read-only /usr.
> 
> It's not a bad idea in server environments either, since it really only
> matters at boot time. Once the file systems are established and in
> place, you're all set.

Your response only concerns booting/mounting. That doesn't even approach
half of the task of properly administering a system/network though.
There are many historical reasons for partitioning drives, and they are
not all purely historical, which is why there is no standard
partitioning scheme. For example, one reason is dealing with backups. If
you use ZFS, NILFS, or some other filesystem that allows concurrent
readonly checkouts of a running filesystem, then maybe it's a non-issue
and you can do what you want. Otherwise, being able to (re-)mount a
portion of your system read-only makes a lot of sense. You can't do that
(easily) if you just toss everything into one bucket.  Likewise for
recovery, the task is easier if the bits to recover are logically
portioned. There are additional reasons/use-cases. Bottom line: just
because the system is booted, you are *not* (as you claim) all set.

Note that many proponents of a merged /usr are concerned with fast boot
times (important on laptops/desktops that get turned on and off often),
not necessarily long uptimes. The change won't affect uptime, but if you
are concerned with a machine that has uptime measured in 5-year
increments, then saving 10 seconds of boot time won't really matter.
This is really specifically a desktop-oriented change for users/systems
that need to boot often, and need to boot with a specific initramfs
setup that relies on /usr being present. (Also see my discussion below
about a merged / instead of a merged /usr).

> The advantage of using it in virtualized environments to share a
> read-only /usr among many guest VMs could be significant.

Having a separate /usr does not preclude one from having a read-only
/usr. There is nothing that prevents one from additionally having a
read-only /. It all depends on the particular partitioning scheme. If
you properly isolate directories that need to be written to as separate
partitions, then you can mount those read-write and everything else
read-only. Also note that distros like RedHat/Fedora use SELinux, which
presumably makes the need for read-only (as a security measure, not for
backups) moot if it does its job properly.

Essentially the push for moving everything into /usr came about because
of how many distros now boot the systems (for increasingly
desktop environments), where they rely on /usr being mounted via
initramfs before the real root system comes up. If they have to rely on
/usr being mounted, why not push everything to /bin and /sbin instead?
The merged /usr proponents claim that historical partitioning is purely
arbitrary and no longer needed, yet a merged /usr (as opposed to merged
/, etc.) is also an arbitrary choice. In fact, merging everything to /
would produce less breakage of existing systems, since / is certainly
needed on all systems before /usr is, so pushing to / wouldn't break
existing boot setups.

The push for a merged /usr is purely arbitrary. I can't recall its name
now, but there was a distro that tried to put every package in its own
directory, much like how programs install themselves under "Program
Files" in Windows. Having a merged /usr (pushing every bin into one
directory) would be just as arbitrary as completely separating every
package. It all depends on how you, as the admin, *want* to partition
your data/binaries, and that is a choice that really should be left to
the admin.

-- 
Justin "flux_control" Boffemmyer
Cauldron wizard and general mage
Source Mage GNU/Linux
http://www.sourcemage.org

Attachment: pgpNsrRJnaoJb.pgp
Description: PGP signature