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

The case for the /usr merge

Posted Jan 31, 2012 16:38 UTC (Tue) by wookey (guest, #5501)
In reply to: The case for the /usr merge by drag
Parent article: The case for the /usr merge

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.

to post comments

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