[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: rootfs



On Sat, Apr 20, 2013 at 09:43:08PM +0100, Kevin Chadwick wrote:
> > I am, as a matter of fact, subscribed to the FHS list.  If you read
> > the specification, you'll see that it does not in any way require
> > /usr to be a *mountpoint*; it can be located on the root filesystem
> > without any problems.  It's actually the default partitioning method.
> > 
> 
> > Do you have any concrete reasons to have /usr separate from / ?
> 
> You need to look at the rootfs section, having them separate makes what
> should be the most critical filesystem (rootfs) 100s! of times larger
> and that quite rightly contradicts the spec (good reasons are mentioned
> but some more benefits of this practice could be included however).

The problem with the FHS here is that it's outdated with respect to
current hardware, the implication of package management, and current
admin practices, and is quite frankly wrong in some aspects.  Taking
each one in turn:

• "The contents of the root filesystem must be adequate to boot, restore,
   recover, and/or repair the system."

  No problems with this. However, having /usr on the rootfs does not
  interfere with this in any way.

• "To boot a system, enough must be present on the root partition to mount
   other filesystems. This includes utilities, configuration, boot loader
   information, and other essential start-up data. /usr, /opt, and /var are
   designed such that they may be located on other partitions or filesystems."

  The keyword here is "may".  /usr may be located on another filesystem,
  but there is not a strict requirement for that.  There's no "should" or
  "must" here.  Note that other distributions have removed the possibility
  for a separate /usr *entirely*.  I'm not suggesting we should go that
  far; but a separate /usr is pointless with a package managed
  distribution.  The creation of modern package managers rendered a
  separate /usr pointless right back in the mid '90s, but it's perhaps
  only in the last few years that we've collectively begun to fully
  appreciate the implications.

• "To enable recovery and/or repair of a system, those utilities needed by an
   experienced maintainer to diagnose and reconstruct a damaged system must be
   present on the root filesystem."
  "To restore a system, those utilities needed to restore from system backups
   (on floppy, tape, etc.) must be present on the root filesystem."

  This is also fine; but having /usr on it does not affect this at all.

• "The primary concern used to balance these considerations, which favor
   placing many things on the root filesystem, is the goal of keeping root as
   small as reasonably possible. For several reasons, it is desirable to keep
   the root filesystem small:"

   "It is occasionally mounted from very small media."

   What does "small" mean nowadays?  We are no longer booting rescue
   systems from floppy discs.  We are using ISO images on CDs/DVDs,
   USB pendrives, rescue partitions etc.  Realistically, these all have
   a capacity of half a gigabyte or more--more than plenty for an entire
   system.  We no longer have serious size limitations--all these
   methods involve the use of media whose size is much greater that the
   maximum HDD size when the FHS was first conceived!

• "The root filesystem contains many system-specific configuration files.
   Possible examples include a kernel that is specific to the system, a
   specific hostname, etc. This means that the root filesystem isn't always
   shareable between networked systems. Keeping it small on servers in
   networked systems minimizes the amount of lost space for areas of
   unshareable files. It also allows workstations with smaller local hard
   drives."

  This part is, frankly, complete bollocks.  /usr is not, and *has never
  been* shareable at all, in reality.  It's technically possible of
  course, but this is to ignore the consequence of a modern package
  manager.  That is to say, you /could/ do it, but it would be
  unremittingly stupid.
    With a package manager, all filesystem locations under the control
  of the package manager are a *unified whole*.  They are *managed*.
  By the package manager.  It's not possible to share /usr between
  systems any more than /etc or /var.  That would get everything
  horribly out of sync, and has the potential to completely screw up
  horribly.  Think of how the dpkg database being inconsistent with the
  real state of /usr, the effect of maintainer scripts and multiple
  hosts all modifying a shared /usr, and you quickly realise that it
  just can't work.  Even if you share it read-only, no system can then
  update its rootfs or /var.
    However, sharing the *entire* system read-only works very well,
  especially when coupled with a unionfs writable overlay.  This is
  what Debian-Live does.

  There's an oft-repeated meme that sharing /usr is a good reason for
  having a separate /usr.  But it's simply not workable in reality.
  I've so far found only *1* person claiming to do this; and when
  asked to demonstrate how they could reconcile this with the
  package manager issues above, failed to explain how it worked
  (it didn't work at all, of course, at least not without a lot of
  custom hacks which negated the value of having a package manager in
  the first place; certainly not something that we can ever support).

  This last "worked" when SVR4 was installed centrally from tape sets;
  maybe possible with Slackware.  But it was always kind of broken for
  them as well, and is entirely broken for any distribution using a real
  package manager.

• "While you may have the root filesystem on a large partition, and may be able
   to fill it to your heart's content, there will be people with smaller
   partitions. If you have more files installed, you may find incompatibilities
   with other systems using root filesystems on smaller partitions. If you are
   a developer then you may be turning your assumption into a problem for a
   large number of users."

  This is a bit of a nebulous one.  And it ignores the fact that vastly
  more people run into problems by partitioning too finely and then
  running out of space one one of the small partitions--it's rather
  more sensible and flexible to have less partitions with more space.
  This is of course exactly the issue in this thread--a full rootfs
  while /usr had gigabytes of free space.  With both on a single
  filesystem whose LV could be grown on demand, this would be a non-
  issue.

• "Disk errors that corrupt data on the root filesystem are a greater problem
   than errors on any other partition. A small root filesystem is less prone to
   corruption as the result of a system crash."

  Like sharing /usr, this is a very common claim, but I've never seen any
  hard evidence to back it up, i.e. actual statistics.  Additionally,
  - It's more common for the rootfs to be writable, so there's a far
    higher chance that it will be the rootfs that gets corrupted.
  - With a package manager, if any of the rootfs, /usr or /var are
    damaged, you need to either restore the entire set from a backup
    or reinstall.  This comes back to the fact that all locations under
    the control of the package manager are a unified whole: if one part
    breaks, the whole thing breaks; more partitions may introduce more
    failure points.
  - The solution here is backups, not partitioning strategies that most
    likely have zero impact on the ability to restore a system to a
    working state.  If your disc is dodgy, you're going to replace it
    rather than futz around with fixing corrupted filesystems and then
    try to get the package state back in sync over all the separate
    filesystems.

I hope this makes clear why I currently hold the position that /usr
(*as a separately mountable filesystem*) is not a useful feature.
I long held the opposite opinion very strongly, until I spent a good
bit of time really considering the validity of all the assumptions
behind why we consider it useful, and came to the conclusion that it
was, for the most part, not useful in the slightest on a modern
package managed system.


Regards,
Roger

-- 

  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux    http://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-    GPG Public Key      F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


Reply to: