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

The case for the /usr merge

Posted Jan 31, 2012 17:36 UTC (Tue) by raven667 (subscriber, #5198)
In reply to: The case for the /usr merge by wookey
Parent article: The case for the /usr merge

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