Re: rootfs

[Kevin Chadwick <ma1l1ists@yahoo.co.uk>]

> 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.
> 

But it is better to be able to.

> • "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.

However this is affected by the rootfs reliability (below) where I
disagree with you.

> 
> • "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!
> 

Why make an assumption that limits the system. Will this change be
applied to debian embedded.

> • "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).
> 

Some on the Gentoo list say they do this but it is no conern of mine.
You can always create a copy of parts and manage that.

>   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.
> 

Except if you fill the system with packages and have no space for more
important things (root does have an extra 5%, perhaps apt should run
as _apt?). This premise also does enforce what should be common sense
(like not putting GBs into /etc) onto packagers which they clearly
sometimes don't have such as putting configs in /usr and binaries
in /usr/lib.

> • "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.

They are equally likely to be writable but there are millions more
writes to /usr and millions more reads when hdd heads or even surges
could damage filesystems. Increasing the chances of mounting and
booting to a rootfs potentially with user customisations or additions
of special tools is surely a good thing and cannot be properly replaced
by busybox.

It also means rootfs backups are quicker and so possibly more frequent.
Filesystems that autobackup don't negate hardware failures.

>   - 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.

Not really, there is nothing stopping you from fixing just what is
broken.

>   - 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.
> 

And what if what you have to recover is in /etc, perhaps a key you
don't want in a backup or a backup failed. You now have gigabytes to
search through perhaps using TCT which cannot be done on a dodgy disk.

> 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.
> 

I see the opposite. Why is it useful to have them amalgamated when
distros like Ubuntu for non technical/admin users do so anyway.

> 
> 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
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org 
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org Archive:
> [🔎] 20130420223113.GK1408@codelibre.net">http://lists.debian.org/[🔎] 20130420223113.GK1408@codelibre.net
> 


-- 
_______________________________________________________________________

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
_______________________________________________________________________