[fhs-discuss] static sharable files

[Roger Leigh]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
Url : http://lists.linux-foundation.org/pipermail/fhs-discuss/attachments/20110509/2451a781/attachment.pgp