The case for the /usr merge [LWN.net]

The case for the /usr merge

Posted Jan 27, 2012 0:42 UTC (Fri) by tchernobog (subscriber, #73595)
In reply to: The case for the /usr merge by cantsin
Parent article: The case for the /usr merge

As explained in the article, booting without a /usr has been broken for years. That kind of support nowadays goes into a ~12MB initramfs. It won't be fixed even without the /usr move, as the initramfs + busybox and friends works well enough.

The idea of having /usr containing everything a system might want after booting (in terms of shared resources) is better, especially if you want to share it as a network filesystem or mount different guest systems using the same kernel.

For instance, to keep updated a distributed environment like a university lab you wouldn't have to care if running an update writes in /usr/bin (only one instance in the network, you update it centrally) or in /bin (changes need to be propagated manually).

Having /var and /etc in the root is because they offer different assets than /usr: they are machine-specific: each machine has its own version with its own configuration and spool directories (think of /var/mail). Binaries and shared files instead pertain to /usr.

Incidentally, if you were to put the whole /usr on a slower disk, considering 90% of libraries in use by a running system are in /usr/lib(64) and executables are in /usr, you wouldn't perceive much of a difference in performance. You'd waste your money on a SSD then. If you want to check, just try opening the normal applications you use (I don't know: firefox, evolution, libreoffice...) and run:

sudo lsof | awk '$9 ~ /^\/([s]?bin|lib)/ { print $9; }' | sort | uniq | wc -l
sudo lsof | awk '$9 ~ /^\/usr\/([s]?bin|lib)/ { print $9; }' | sort | uniq | wc -l

This actually doesn't tell you the whole story, because it should be seen also how many files are read at application startup from other directories such as /usr/share (all icons, desktop files, resources, databases, etc.). That bumps up the number considerably.

to post comments

The case for the /usr merge

Posted Jan 27, 2012 2:06 UTC (Fri) by fest3er (guest, #60379) [Link]

For most desktop/server systems, there's little reason not to build the standard initramfs to contain everything needed to explore and repair a broken system. I did this, at least partly, with Roadster, my version of Smoothwall I've been developing. The install initramfs contains a usable user environment for checking hardware, exploring disks, hacking the installer, and other stuff.

In fact, the standard initramfs *needs* a number of utilities in order to boot the system anyway. So put all the necessary booting/fixing progs in the initramfs, and put everything in /bin and /lib on the hard drive. Building with '--prefix=/' will handle most of it; the rest is in system-specific scripts and config files.

That said, I can still see a good reason to keep /usr separate. Keep the most commonly used utilities, programs and libs in / and put the rest in /usr: it may well make it easier to keep /bin, /sbin and /lib dirs cached (the dirs, not necessarily their contents). The less you have to hit the disk, the faster the system will be.

The case for the /usr merge

Posted Jan 27, 2012 4:47 UTC (Fri) by steffen780 (guest, #68142) [Link] (1 responses)

Booting without /usr has been broken for years? How curious, I'm doing that right now and I hardly have what I'd call stale software (kernel 3.2.1, gcc 4.6.2, kde 4.8.0, ...). So I can't boot? That's rather annoying indeed!

The case for the /usr merge

Posted Jan 27, 2012 5:34 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

In this context "broken" means "will fail to work under various circumstances in which you would expect it to work" rather than "will fail under all circumstances". The work required to make separate /usr work in all circumstances would involve moving a large part of /usr to /, which kind of defeats the point.

The fundamental problem with a separate /usr is that writing a tool that may be used in the booting of some estoric platform or setup would require you to limit yourself to the libraries available in /. Those vary across distributions, so which subset do you use? If you want to use a library that's in /usr, do you duplicate the functionality in your code or get every distribution to move it to /? What if that library has dependencies on a pile of other libraries that are currently in /usr as well? The / and /usr divide artificially split the platform in two, without any clear semantics as to which subset of functionality you can actually depend on. The world has got more complicated than it was when the worst case was /usr being on an NFS server connected by ethernet. Something has to change.