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

The case for the /usr merge

Posted Jan 27, 2012 18:13 UTC (Fri) by raven667 (subscriber, #5198)
In reply to: The case for the /usr merge by paulj
Parent article: The case for the /usr merge

a) standardizing and simplifying management make supporting remote /usr easier
b) in a shared /usr system packages would only be installed on the file server system so the clients wouldn't need the package tools or database
c) I think you probably can share /usr, at least some people wish to have that capability cleanly and safely.

To have a shared system with everything in / you'd need seperate mount points for at least

/bin
/include
/lib
/lib64
/libexec
/sbin
/share
/src

rather than one mount point for /usr which seem simpler.

to post comments

The case for the /usr merge

Posted Jan 28, 2012 12:26 UTC (Sat) by rleigh (guest, #14622) [Link] (2 responses)

This sort of approach is no longer useful, IMO. Why would you /want/ a remote /usr? That is to say, when you can even more easily have a remote / (which includes /usr)? This makes no sense in a package-managed environment where / and /usr are a managed whole. Modern systems have so much disc space, that sharing /usr between systems is a historical curiosity only. By all means share the /entire/ rootfs, but /usr separately is not useful.

Regards,
Roger

The case for the /usr merge

Posted Jan 29, 2012 22:19 UTC (Sun) by elanthis (guest, #6227) [Link]

Storage is not the problem. It has _never_ been the problem, even back when storage was small and not necessarily that cheap. Management is the problem. These are of course problems many Linux users are not familiar with, as their Linux experience is basically limited to "I run a Web server out of my mom's basement and I put Ubuntu on my laptop 'cause I'm such a tech-rock-star woooo go me!" Folks who have to or had to manage large rollouts of dozens, hundreds, or thousands of servers or workstations are the audience of separate /usr these days, not the masses of Linux fans.

I don't want to have to upgrade 10,000 machines individually. I want to upgrade one network image, and have all 10,000 machines automatically get the update next time they reboot and attach to the network share. (Noting that this is doable by versioning the images, having new connections always get the newest image, and existing connections retaining the image they already had.)

And when doing that, I want to have ONE network share to update, so there are no race conditions or such when a client is halfway through mounting /bin, /lib, /share, etc. and the rollout kicks in.

Finally, / itself can't just be the share point, because if it is to be read-only then /var, /etc, /home, /tmp, and so on would be screwed. The best you could do would be to put something like "/var /dev/sda1" into the network-mounted /etc/fstab, but then various other bits of machine-specific data need a lot of hacks to get working correctly. I've seen people try these hacks, like putting /etc on a separate network share and serving different images based on MAC/IP that are known to correlate to different hardware configurations... but man is that a lot of work and very error-prone.

The case for the /usr merge

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

> Why would you /want/ a remote /usr?

If you have an environment with 100,000s of virtual machines, you want it. Package management is not a problem there, it happens on the server; /etc on local systems is controlled by Chef/Puppet/some other SCM system.