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

The case for the /usr merge

Posted Jan 27, 2012 11:10 UTC (Fri) by njwhite (subscriber, #51848)
Parent article: The case for the /usr merge

The reasons for the /usr merge make a lot of sense, and I'm glad the arbitrary and confusing distinction between / and /usr are going away.

However I still don't really understand why dispatching of /usr and sending its directories into / isn't sensible. The only reason given in Fedora's FAQ is that it would mean mounting a few more network shares to get the OS over the network, but that doesn't sound like much of a hurdle to me. I'd just like /bin to contain all binaries, directly (not as a symlink). This solution has the most clarity to me. Can anyone explain slower why merging to /usr rather than to / is significantly better?

to post comments

The case for the /usr merge

Posted Jan 27, 2012 11:59 UTC (Fri) by rleigh (guest, #14622) [Link]

I am a strong proponent of this strategy. It makes logical sense that were / and /usr to be unified, we only need the root. We can just have a /usr → / symlink for backward compatibility.

The primary issue is one of upgrading; it's common to have a small / and large /usr, in which case users would run out of disc space on upgrade due to their / being filled up. However, migrating the smaller content of / to /usr is less likely to fail. This would not be an issue for clean installs. Given the appropriate documentation, and resizing of partitions prior to an upgrade, this is possible to work around.

The advantages are numerous, and it makes long-term sense to unify the two. On a modern package-managed system, the two are intimately tied, and the historical reasons for the split no longer apply. It's not just library dependencies that become simpler, we also have access to the glibc locale data from the moment init starts, meaning that it's possible to use UTF-8 locales in early boot, in addition to having no chance of NSS or PAM modules failing due to missing dependencies.

Regards,
Roger

The case for the /usr merge

Posted Jan 27, 2012 12:08 UTC (Fri) by angdraug (subscriber, #7487) [Link] (6 responses)

Check the comment by jmorris42 earlier in the thread, he's already explained why it would be nice to have /usr with all the executable files in it mounted read-only at all times, except when you're upgrading the system. The security benefit alone is tremendous.

The case for the /usr merge

Posted Jan 27, 2012 12:15 UTC (Fri) by njwhite (subscriber, #51848) [Link] (2 responses)

The security benefit of mounting read-only is marginal. If a user has access to write files which are marked read-only in the filesystem, they have access to remount /usr read-write. Unless I'm missing something?

The case for the /usr merge

Posted Jan 27, 2012 16:52 UTC (Fri) by raven667 (subscriber, #5198) [Link]

Read-write access can be controlled at the server for networked filesystems and not overridden by the client. Even in a local filesystem case it can prevent accidental modification or break canned exploit scripts

The case for the /usr merge

Posted Jan 27, 2012 18:31 UTC (Fri) by iabervon (subscriber, #722) [Link]

Just having /usr mounted read-only isn't that big a win, but if the system will work with /usr mounted read-only, it will also work (which real benefits) if /usr is storage the system is technically incapable of modifying. (That is, where changing it requires doing something entirely different, like swapping CDs or flipping a physical switch on the device or something like that; or where it is a different system which can modify it.)

The case for the /usr merge

Posted Jan 27, 2012 18:08 UTC (Fri) by jmorris42 (guest, #2203) [Link] (2 responses)

And I just had another thought along those lines.

With this change /usr is basically the same as \Windows, the whole OS is in one directory except we are smart enough to pull out the dynamic info into /var and /etc. Now we just make /etc a symlink to /var/etc and we get the whole operating system down to two directories, one per host changing information and one static read only binaries, libraries and documentation.

Of course they are also busy repolluting / with new top levels, otherwise we could look forward to a root with only:

/boot for the boot loader, kernel and initrd
/dev
/home for users
/media as the modern replacement for /mnt
/opt, probably can't get 3rd party vendors to give up on that one.
/proc for the kernel
/root since it probably can't go in /home/root safely
/sys for the kernel
/usr for the OS
/var for the OS

Plus symlinks for /bin, lib and /sbin. But I currently have /cgroup, /run and /srv cluttering things up. Why did we need those others in root and not somewhere under /var or /sys?

The case for the /usr merge

Posted Jan 27, 2012 20:08 UTC (Fri) by sytoka (guest, #38525) [Link] (1 responses)

/lib64 is just horrible. Debian have a nice solution for multi-arch that will be maybe in wheezly....

The case for the /usr merge

Posted Jan 28, 2012 12:27 UTC (Sat) by Wol (subscriber, #4433) [Link]

Are they changing release names from Toy Story to Harry Potter? :-)

Cheers,
Wol

The case for the /usr merge

Posted Jan 28, 2012 4:43 UTC (Sat) by rgmoore (✭ supporter ✭, #75) [Link] (9 responses)

I think the underlying idea is to move all of the program stuff that can potentially be shared between systems to /usr and leave the system specific stuff like /etc on /. That way you can have /usr on a network share, probably mounted read only, with only a minimal / partition. As I see it, there are two reasons this is a better solution than moving everything from /usr down to /:

There are things that exist in /usr that don't currently exist in /, like /usr/share and /usr/src. That means merging /usr down to / doesn't just involve moving binaries and libraries to different directories; it means you have to add a bunch of directories to /, which is generally frowned upon.
Related to this, moving stuff down to / is messy if you want to network mount your binaries (one of the goals of the project) because /usr has a bunch of directories. On my system, /usr has 11 subdirectories, so fully sharing it as separate directories under / would involve 11 separate mounts.

So the options are pushing everything into /usr, which lets you mount your binaries from the network with 1 mount and requires 4 symlinks in / for backward compatibility, or pushing everything down to /, which requires 11 mounts to network everything and 11 symlinks in /usr for backward compatibility. Pushing stuff up into /usr sounds a lot simpler to me.

The case for the /usr merge

Posted Jan 28, 2012 23:43 UTC (Sat) by lindi (subscriber, #53135) [Link] (7 responses)

How would sharing read-only /usr really work in a distro with package management? The package management state would be in /var anyway, how would it then track files in /usr?

The case for the /usr merge

Posted Jan 29, 2012 7:30 UTC (Sun) by raven667 (subscriber, #5198) [Link] (5 responses)

The simplest solution seems to be to manage the packages on the file server, just share out its /usr. Trying to manage packages on the client systems is folly for the reason you mentioned and probably others.

The case for the /usr merge

Posted Jan 31, 2012 5:11 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link] (4 responses)

That lets you manage the packages, but it doesn't fix the problem of packages that want to put files outside of /usr, especially into /etc. You'll need some way of getting any updated files from the server to the rest of the systems. Some of that is probably a sign that /etc needs a serious cleanup- there's a fair amount there that looks as if it belongs in /usr/share rather than /etc, and some of the other configuration stuff might be better done dynamically- but even with a well managed distribution there's going to be a need for updated files in /etc.

The case for the /usr merge

Posted Jan 31, 2012 7:22 UTC (Tue) by raven667 (subscriber, #5198) [Link] (1 responses)

The cases where there is a shared /usr implies a degree of sophisticated system administration already, probably capable of rolling out more complex changes if necessary when there is a platform update. That said, the common case is going to be patch deployment that should not require changes outside of /usr and for admins used to RHEL they won't expect intra platform upgrades anyway.

Actually thinking of RHEL I see a use case for virtualized servers where many OS instances share /usr but have private /var, /etc and /opt. That could provide great gains in memory and disk dedup for "free"

The case for the /usr merge

Posted Jan 31, 2012 19:35 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link]

Actually thinking of RHEL I see a use case for virtualized servers where many OS instances share /usr but have private /var, /etc and /opt. That could provide great gains in memory and disk dedup for "free"

Virtualized machines is one of the use cases they mention specifically. The idea is that with all of the binaries and libraries pushed into /usr, / will shrink to something quite small and it will be easy to give every server its own copy without wasting much space. Cleaning up /etc would make management easier and save space for that kind of virtualization.

The case for the /usr merge

Posted Jan 31, 2012 13:17 UTC (Tue) by bluss (guest, #47454) [Link]

Maybe union-mounted /etc and /var?

The case for the /usr merge

Posted Feb 2, 2012 17:47 UTC (Thu) by jschrod (subscriber, #1646) [Link]

Environments that want to share /usr probably use tools like Chef or Puppet to control the content of /etc anyhow. At least, we do. ;-)

That said, there are really many files in /etc that are there for historical reasons and could go to /usr/share, IMHO.

The case for the /usr merge

Posted Jan 29, 2012 10:55 UTC (Sun) by nix (subscriber, #2304) [Link]

On a system with read-only /usr, you would of course make the package-management directories in /var symlinks into somewhere under /usr. Package management state is then shared.

The case for the /usr merge

Posted Jan 29, 2012 0:58 UTC (Sun) by dlang (guest, #313) [Link]

however since package managers don't know how to deal with a /usr that's shared between machines (an update isn't confined to only making changes within /usr) I really question the value of this argument as a practical matter.

I tend to build my machines using /, /var, and a spare / (for upgrades rollback) but that doesn't mean that all files that are in subdirectories should get moved up.

it seems like a lot of this is to work around problems in the rpm packaging system, and that the arguments against it are dismissed because 'fedora is broken in that situation anyway'