On Mon, May 09, 2011 at 09:33:48AM +0200, Tollef Fog Heen wrote: > ]] Bruce Dubbs > > | Currently the FHS has a discussion in Chapter 2 about sharable and > | unsharable files that are static or dynamic. > | > | The example shows /usr as a prototypical static, shared directory. The > | implication is that /usr can be mounted from a remote host. > | > | The problem is that /usr has become a place that is necessary before a > | network mount is available. For instance, if an administrator finds it > | necessary to use lspci, or lsusb before the networked /usr is mounted, > | the pci.ids and usb.ids files are not available. > > I think > http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken > is relevant in this context.
These threads also contain issues pertaining to the / vs /usr split: http://lists.debian.org/debian-devel/2009/05/msg00075.html http://lists.debian.org/debian-devel/2011/01/msg00006.html But all of the existing issues identified by having the separation fail to address an even bigger issue: sharing /usr is entirely incompatible with a modern package manager, and this has always been the case. See: http://lists.debian.org/debian-devel/2011/01/msg00152.html In this message, I've detailed various historical use cases for a separate /usr, together with brief pros/cons/rationale. On a modern Linux system, most of these make zero sense, and it is preferable to have them on the same filesystem. This summary is the most important point (refers to dpkg, but applies to all package managers): "I think many instances of confusion and misunderstanding over the / and /usr separation, particularly with regard to NFS mounts, but also covering read-only mounts and recovery are due to not fully considering the implications of a modern package manager on the traditional UNIX filesystem hierarchy. We can consider that there are just two different types of directory in the file system: • those managed by dpkg • those containing user data which are not under dpkg control All locations managed by dpkg must be considered a unified whole; it does not make any sense to share one part and not another. They must be updated together or else the system will be left in a broken and inconsistent state. A separate /usr is no longer required to boot the system now we have initramfs." > Another option is to deprecate or disallow /usr not being on the root > file system. > > Separate /usr made sense back when drives were small and disk space was > expensive, but in the vast majority of cases today, having /usr on the > root file system is no real burden. Not having it on the root file > system means more brittle setups and trying to share /usr between > installations can easily lead to maintenance headaches. > > Separate /usr makes sense is in the embedded case where you are > seriously space-restricted and you might want have your OS on fast flash > and the apps and user data on cheaper, but slower flash. In those > cases, I'd suggest putting apps in /opt rather than the more common > /usr. This makes a lot of sense. From the FHS POV, I would like to suggest these changes: • "/usr is shareable, read-only data" - Remove the "shareable" qualifier. With a package manager such as dpkg or rpm etc., it does not make any sense to share /usr since the content is managed as a whole with the other contents of /, including conffiles. - While it's technically possible to share /usr, this requires a lot of additional custom support scripts to sync the configuration files and other parts of the software not provided under /usr; no distribution caters for this use case directly. - Even when you don't have a package manager, you still have the issue with the configuration files not being shared (as pointed out elsewhere in this thread). • Sharing / works, so permit sharing of / (which would include /usr) - Sharing a read-only / allows use on many hosts; host-specific configuration can be stored in a writable aufs/unionfs overlay, or on /run (for example). • Permit /usr to be a symlink to /. This gives distributors the option of unifying the / and /usr namespaces. This is a logical consequence of keeping / and /usr on the same filesystem. In the distant future it might be possible to eliminate /usr entirely, but at this point it would be appropriate to have the option of making it a symlink. Related to /usr it would also be good to: • Remove the special treatment for /usr/X11R6; we no longer need it now X uses the standard hierarchy (same as for /usr/games). Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
signature.asc
Description: Digital signature
_______________________________________________ fhs-discuss mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss
