| |||||||||||||
The case for the /usr mergeThe case for the /usr mergePosted Jan 28, 2012 4:43 UTC (Sat) by rgmoore (✭ supporter ✭, #75)In reply to: The case for the /usr merge by njwhite Parent article: The case for the /usr merge
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 /:
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.
(Log in to post comments)
The case for the /usr merge Posted Jan 28, 2012 23:43 UTC (Sat) by lindi (subscriber, #53135) [Link]
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]
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] 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]
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 engla (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 (✭ supporter ✭, #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'
|
|||||||||||||