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

The case for the /usr merge

Posted Jan 27, 2012 17:01 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

I'm not sure what this has to do with storage, you'll need the same amount of space in either case. For a locally installed system it doesn't make sense to have /usr be a seperate mount point at all. Where keeping stuff in /usr makes sense is in the remote mount situation so that there is one mount point needed, also look at how many subdirectores are in /usr, do you really need them all in / and all with separate mountpoints? That seems obviously less clean and organized than just centralizing the system into /usr.

to post comments

The case for the /usr merge

Posted Jan 27, 2012 17:33 UTC (Fri) by paulj (subscriber, #341) [Link] (4 responses)

Well, I wasn't intending to get into an argument about the merits of a separate /usr. Storage is cheap in that there is no merit locally in having a separate /usr for either speed or convenience of rescue (i.e. any media you might use for rescue will almost certainly be big enough for a full system). As for remote mount:

a) It's been a *long* time since this was supported by distros.

b) Package management generally can't cope with shared /usr's (Solaris IPS is the only modern one I know of that tried to, for zones - but it's hard & I don't know if they succeeded).

c) If you can't share /usr's, then there's no real point having a separate /usr - just remote mount the whole /.

As for /usr/ having lots of directories, and that it'd pollute /:

# for H in /usr/* ; do printf "%14s in /?: " $H ; [ -d ${H#/usr} ] && echo yes || echo no ; done
/usr/bin in /?: yes
/usr/etc in /?: yes
/usr/games in /?: no
/usr/include in /?: no
/usr/lib in /?: yes
/usr/lib64 in /?: yes
/usr/libexec in /?: no
/usr/local in /?: no
/usr/sbin in /?: yes
/usr/share in /?: no
/usr/src in /?: no
/usr/tmp in /?: yes

Half the /usr dirs are in / already (actually, one of them is same directory). Of the rest, at least 1 or 2 are system directories (libexec, share) that should be kept in the system directory (i.e. /, if you're moving to /). Which leaves games, local src and include. Those could stay in /usr I guess (/usr will have to stay anyway, to keep backwards-compat symlinks).

The case for the /usr merge

Posted Jan 27, 2012 18:13 UTC (Fri) by raven667 (subscriber, #5198) [Link] (3 responses)

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.

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.