> 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-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org Archive: > http://lists.debian.org/20130420223113.gk1...@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) _______________________________________________________________________ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130421010948.66777...@kc-sys.chadwicks.me.uk