The case for the /usr merge [LWN.net]

The case for the /usr merge

Posted Jan 27, 2012 6:28 UTC (Fri) by drag (guest, #31333)
In reply to: The case for the /usr merge by rickmoen
Parent article: The case for the /usr merge

> 1. That's only if you're still keeping a separate /boot filesystem, for starters. (Why in 2012, by the way? The 1024-logical-cylinder limit on x86 went away ages ago.)

Yes. /boot.

The reasons you have /boot are for:

* Encrypted Root
* LVM
* File systems not supported by Grub
* Network boot
* Non bootable RAID devices (including software raid)
* Union file systems for /
etc etc.

How Linux works now is this:

Bios --> Executes boot loader
Grub --> Loads kernel + Initrd into ram and executes them

The purpose of having a /boot is to provide a platform for bootloader, of which Grub2 is one of many possible loaders, for boot strapping the kernel and initrd.

Initrd performs the necessary functions to get a root file system built up and configured correctly. Starts up software raid, mounts encrypted file systems, performs consistency checks, and can even provide for a emergency repair console if distributions choose to set it up that way.

The initial root file system in ram can perform all the necessary functions that originally having a separate / and /usr directory was meant to accomplish. Only now the 'kernel + initrd' is massively more robust and more flexible then a separate / ever was. Initrd is self contained, executes in ram, and can be loaded in dozens of different ways without breaking it and without it caring how it got loaded.

/boot is just the standard for boot strapping your system on x86 systems with a local hard drive. However there are many different ways it can be done.

A few commonly used examples:
* Load your kernel/initrd from PXE network boot
* Load it from a ISO with isolinux
* Load it from USB drive with syslinux
* Specify a abritrary kernel and initrd to be executed by Qemu/KVM via the command line or Libvirtd XML for launching virtual machines.

All sorts of stuff beyond that. Things that you could never, ever, pull off with trying to do a separate / partition, without massive headaches and all sorts of problems.

So not only has the most significant purposes of having a separate / file system have superseded by superior technologies, but having a separate / file system, for purposes of boot-strapping or rescuing the system, has been a fundamentally broken configuration for many years now. It's not just systemd or Lennart. It just isn't going to work well except in specific hand-crafted setups.

Try it for yourself sometime. Get rid of the initrd, make a custom kernel with everything you think you need, and try to boot / locally while mounting /usr over nfs. It can be done, but it's going to be a headache.

Seriously. I am surprised that somebody would think to try to defend a separate / while lambasting the idea that a separate /boot is necessary. If anything it would make more sense to try to use /boot to help defend the idea that preserving the ability to use a separate / would be necessary.

> Yeah, thanks loads, Lennart. So, every time I have to maintain fsck, filesystem-diagnostic, backup/restore, etc. contents that would normally be in /bin, I have to rebuild an initramfs filesystem image. Swell.

I don't know why you are thanking Lennart. You should be thanking hundreds, if not thousands of people, who put about 20 years of Linux operating system development into practice.

Have you not noticed that when ever you perform a significant system update on you rebuild your initrd? When you install lvm tools, or software raid stuff, or encrypted file system support that this usually causes your initrd to be be rebuilt. It's been like that for a long time.

to post comments

The case for the /usr merge

Posted Jan 31, 2012 16:38 UTC (Tue) by wookey (guest, #5501) [Link] (4 responses)

This is a very x86 PC-centric view. It is not 'how Linux works' in a more general sense. Other hardware boots in various other ways, not involving BIOS or GRUB, and may or may not have an initrd.

An initrd slows things down quite significantly which is a big deal for some use cases. It provides great advantages in terms of single-boot-image generality and ease-of-rescue but also a cost in speed (and size, although that's small these days at ~2-10 Mb compressed). Boot speed and image generality tend to be in direct competition.

And to answer another post further up, plenty of 'fairly embedded' machines provide a (serial or USB or LCD) console though which rescue can be done and you don't simply want to re-flash and (for example) lose 3 years of logging data. I am thinking of the balloon board controlling my heating system in this case.

Whether overall, moving everything to /usr is a good plan remains to be seen. Personally I am skeptical but I have only spent a limited amount of time reading about the implications so far.

The case for the /usr merge

Posted Jan 31, 2012 17:36 UTC (Tue) by raven667 (subscriber, #5198) [Link] (3 responses)

In the common case where /usr is not its own filesystem then it's a simplifying cleanup and a noop for reliability and where /usr is a separate filesystem then making sure you have to tools to mount it in initrd, same as you already need tools to mount the root filesystem. Basically its simpler to make sure the appropriate tools are available in an initrd, which only needs a working bootloader to load, than to limit the design of the system so that the rootfs and /usr must be available without tools to set them up. If you already have an initrd then duplicating that functionality in the root filesystem isn't necessary and if you don't have an initrd then the root filesystem and /usr need to be mountable by the bare kernel without tools.

Is any of that a good explanation?

The case for the /usr merge

Posted Jan 31, 2012 21:44 UTC (Tue) by wookey (guest, #5501) [Link]

Yes, thank you. Put like that I can't see any reason to object to it.

Now lets see what I think after reading the other 250(!) comments...

The case for the /usr merge

Posted Feb 2, 2012 5:44 UTC (Thu) by thedevil (guest, #32913) [Link] (1 responses)

"if you don't have an initrd then the root filesystem and /usr need to
be mountable by the bare kernel without tools"

'Scuse me, I don't follow this part. / yes, /usr no. They can be very
different, after all, /usr can be a network filesystem or more generally
just require a kernel module to mount. Isn't that what the whole debate
is about?

The case for the /usr merge

Posted Feb 2, 2012 7:06 UTC (Thu) by raven667 (subscriber, #5198) [Link]

The point is that the initrd is the appropriate place to put those tools as it can be reliably loaded using he same method as he kernel. You could have a root filesystem that requires a module or network mount so you already need to support this kind of complexity in the initrd. If you don't want an initrd for some reason then this naturally limits the filesystem setup you can boot off of.

The problem with maintaining a split system is that it is currently broken on the major systems and has been for some time. At least a dozen binaries in the base system depend on resources in /usr. Fixing it by moving more of the system into the root directories seems more complex and prone to breakage than relying on the toolkit in initrd. Since all the tools you need are already in the initrd, maintining the /sbin /usr/sbin split doesn't have a point. Getting rid of the split makes the system simpler and more flexible so it seems like the right choice