Why not the other way round?

Posted Jan 10, 2016 10:57 UTC (Sun) by Yenya (subscriber, #52846)
Parent article: Preparing for a merged /usr in Debian

I always wondered why the /usr merge is not done the other way round, i.e. get rid of /usr/bin, /usr/lib, etc., save one iteration inside many calls to namei(), and move everything directly under / (with symlinks like /usr/bin -> ../../bin).

Why not the other way round?

Posted Jan 10, 2016 14:08 UTC (Sun) by raven667 (subscriber, #5198) [Link] (5 responses)

Good question, doing it that way would make all binaries inseparable from the root filesystem, or require each directory to be separately mounted, its simpler to have one filesystem, /usr, that represents all system binaries so that all the top level directories in / represent distinctly different classes of data.

Why not the other way round?

Posted Jan 10, 2016 17:48 UTC (Sun) by bronson (subscriber, #4806) [Link]

> /usr, that represents all system binaries

Too funny. You can never go home.

Why not the other way round?

Posted Jan 11, 2016 12:56 UTC (Mon) by Yenya (subscriber, #52846) [Link] (3 responses)

> doing it that way would make all binaries inseparable from the root filesystem

Of course. Now why this is a problem? Why it is necessary to add another level of indirection to the "dummy" root filesystem instead of having the root filesystem with the binaries, libraries, data files, etc., and have _other_ types of data as mountpoints? After all, this is what has been done to the /var/run directory as well. And we need the binaries, ld.so, etc. in the early stages of boot, so it does not make sense (to me)
to have it on a separate filesystem anyway.

Why not the other way round?

Posted Jan 11, 2016 15:29 UTC (Mon) by anselm (subscriber, #2796) [Link] (2 responses)

“The early stages of the boot” have by now pretty much been taken over by the initramfs, so being able to put stuff into /bin to have it available “from the start” is no longer a viable argument except as far as the most simplistic deployments are concerned.

In addition, not putting all binaries, libraries, etc. directly onto the root file system makes it possible to have a very small root file system (possibly in RAM) which should appeal, e.g., to appliance makers.

Why not the other way round?

Posted Jan 11, 2016 15:47 UTC (Mon) by Yenya (subscriber, #52846) [Link] (1 responses)

I fail to see the substantial difference between

* having a small filesystem (possibly in RAM) for / and mounting binaries from r/only media to /usr,
and
* having these r/only media mounted as / and mounting the said small RAM-based filesystem as /var or /etc.

The only (albeit minor) difference is that the second approach has shorter paths (/lib instead of /usr/lib, etc.).

Also, my argument is not "to have stuff in /bin available from the start" (it can be surely be done for binaries in /bin as well as in /usr/bin), but to avoid having a separate root filesystem and longer paths for no good reason.

Having r/only binaries and r/w variable data on separate filesystems is a valid requirement for some systems. However, this does not imply that the / directory should belong to the former or to the later.

Why not the other way round?

Posted Jan 12, 2016 12:44 UTC (Tue) by smcv (subscriber, #53363) [Link]

> mounting the said small RAM-based filesystem as /var or /etc

OK, so you mount your root filesystem, you look in /etc/fstab for the machine-specific list of what else to mount, oops! you don't have /etc yet.

That's why /etc is required to be on the root filesystem in Debian (and, as far as I know, in all general-purpose distributions). The first filesystem you mount (plus the initramfs, if present) must contain enough configuration to mount the rest. In Debian's support for having the initramfs mount a separate /usr, the initramfs mounts / first, and reads /etc/fstab to find out where /usr is.

It would be possible to hard-code the partition layout in the initramfs (for example by copying /etc/fstab into it), but it seems better to minimize the set of system configuration changes that require an initramfs rebuild before they will actually take effect.

Why not the other way round?

Posted Jan 11, 2016 23:10 UTC (Mon) by Karellen (subscriber, #67644) [Link] (2 responses)

One reason is containers.

To start a new container, you can create your new "root" directory, with (nearly?) empty /var, /home and /etc, mount an appropriate /dev, /proc and /sys, then put a tmpfs on /tmp and /run, and finally bind-mount /usr read-only.... and that's it! Your chroot/jail/container-of-choice is ready to go.

OK, mounting a single /usr is only slightly easier than mounting /bin, /lib and /sbin separately; but the container angle is the one that let me see how /usr is a logical unit of the filesystem that makes sense to have its own top-level subdir.

Why not the other way round?

Posted Jan 12, 2016 9:09 UTC (Tue) by Yenya (subscriber, #52846) [Link] (1 responses)

You forgot to create /lib, /sbin, and /bin symlinks in your container root fs :-) And you still have to populate /var and /etc with something, so the net difference between read-only / with bind-mounted /etc, /var (and maybe /home) and read-write / with bind-mounted /usr and several symlinks in / is quite negligible. And read-only / would allow sharing other things like /opt from the main system.

Why not the other way round?

Posted Jan 13, 2016 0:23 UTC (Wed) by raven667 (subscriber, #5198) [Link]

I think this is not as much of a problem as you think it is, a lot of work has already happened to make booting with an empty / that gets populated on first startup functional.