Merging /usr/bin and /usr/sbin into /bin (GNU/Linux)

Question

I've read quite a number of discussions about people wanting to merge /bin and /sbin into /usr/bin. The same cannot be said for doing it the other way around.

Is there any technical reason why one would not want to merge /usr/bin and /usr/sbin into /bin, or is it mainly a personal preference/design choice?

Answer 1

The reason that things were merged to /usr and not to / are noted in The Case for the /usr Merge:

Myth #11: Instead of merging / into /usr it would make a lot more sense to merge /usr into /.

Fact: This would make the separation between vendor-supplied OS resources and machine-specific even worse, thus making OS snapshots and network/container sharing of it much harder and non-atomic, and clutter the root file system with a multitude of new directories.

Answer 2

You are correct, Fedora is the avante garde of this, although freedesktop.org, an independent body, then took up the cause in hope of encouraging it pan-linux.

According to this, the merge follows a pattern started by Solaris, the "primary commercial Unix implementation". It is interesting in the sense that the original Unix used /bin, and so getting rid of the split might have meant making the directories in /usr symlinks instead of the other way around.

However, considering that option, linking the toplevels is probably more straight forward and obvious.

Answer 3

/sbin and /usr/sbin historically were where statically linked binaries were kept. /sbin for the admin-level commands needed at init level 1 (single user mode) and /usr/sbin for more general admin commands needed at init level 3 (fully networked, remote logins enabled, NFS enabled). Unfortunately, Linux no longer adopts this model.

Answer 4

As a systems engineer, I find the trend deplorable. For example, flash memory has very fast access, but it's also expensive (3x more cost per GB than spinning magnetic disk media) and has problems in that you can only write to it so much before static charge accumulation in the memory bits makes the device unusuable (first soft errors corrected by the device firmware, then hard errors at which point the device marks itself as read-only).

So, we STILL have "fast, expensive memory" and "slower, cheaper memory"

Even On a Raspberry Pi, I would much prefer to have a small 2.5" disk (laptop size) attached to a USB 3.0 port, with all of the essential boot-related stuff on /bin and all of the non-essential ( USER!) stuff in /usr and places with LOTS of write activity, such as /tmp and /var/tmp, and especially /var/log and /var/cache... on a much cheaper, much more durable 1TB 2.5" disk, because those subtrees get written to constantly. When I set up a system, I typically create a few filesystems, precisely for the reason of isolating high write-volume subtrees from medium write-volume subtrees and both from the low write-volume subtrees, and user account filesystem (/home or whatever) kept separate from /var/log.

/opt can be made a pointer into /usr/_opt (I use pre-fix and infix _ characters for symbolic link destinations to indicate where the symbolic link comes from. so /opt becomes a symbolic link to /usr/_opt. /tmp becomes a symbolic link to /mnt/highwrites/_tmp and /var/tmp becomes a symplic line to /mnt/highwrites/_var_tmp. That way, I don't have to guess which of the "tmp" directories is going to need more space... they're both on the same filesystem, and have their frequent and high volume writes safely isolated from all of the other filesystems. And when do log files get written to the most? When something goes wrong...in the kernel. And that's when you REALLY don't want much (or ideally any) filesystem writes going to the root filesystem.

Merging /usr and / was always a bubble-headed scheme, and as much as I admire Sun Microsystems and its history I really don't care if Sun started this insanity. Most important installed suns are expensive enough and critical enough that they have ample system backup resources which are utilized every day. The average linux system doesn't have that kind of capital investment, especially home and small business users.

Therefore, the default configuration should err on the side of safety and minimizing data loss by isolating the majority of filesystem writes by separating out those directories which have the most activity on their own filesystem, rather than unifying the entire filesystem and spreading the problem to the most valuable files (1. user data, followed by executable and directories required for system boot up and damage evaluation and repair (fsck, and dump and restore type programs, and in the event of storage hardware failure, mkfs, mkswap, and a few other useful programs like grep, etc, and of course all of the hardware and some virtual (like RAID) device drivers)

Userland applications tend to be upgraded and bug-fixed much more frequently than the "system essentials" that are traditionally in /bin and /sbin. Keeping that filesystem small and RARELY WRITTEN TO reduces the opportunity for corruption. I don't care much if things traditionally found in /usr gets corrupted, but I absolutely DO care if mount and fsck are on a filesystem that gets corrupted.

Even if you're using a single storage technology (Like a single 1 TB hard disk), it STILL makes more sense have /usr on a separate partition, for the simple reason of keeping the root partition as small with as few writes to it as possible.

As far as "having stuff mounted sooner"... most boot up configurations, as soon as the kernel is loaded, the / filesystem is fsck'ed and then mounted... followed by fsck and mount of each of the other filesystems in the fstab that are configured to mount at boot time, so "quicker availability" isn't an issue. Besides, 10 small filesystems, fsck'ed sequentially can be fsck'ed faster than a single filesystem, because the back and forth head movement of the read-write head are kept to narrower bands, thereby making head-seeks of shorter duration, followed by a slightly longer head-seek to the next partition, whereas filesystem covering the entirety of a single disk can be seeking from inner tracks to far outer tracks and back thousands of times.

The only real disadvantage of dividing up a single disk into multiple filesystems is if you have the majority of write activity on the first and last partitions, rather than on a series of partitions in the middle, and that when a disk does a head seek from a filesystem on one partition to that of another partition, it has to traverse more empty blocks than if it were all in a unified, single filesystem.

All in all, the advantages of a single filesystem are still outweighed by the advantages of dividing a single storage device into several filesystems. And from a reliability and data safety aspect, multiple filesystems, each on its own device, is the preferred (although most expensive) method. Back when parallel SCSI was still common, I used to buy used SCSI disks for cheap... one for /, one for /usr, one for /home, and the smallest (and usually oldest) for /tmp, /var/tmp, and /var/log. That device being typically the smallest, and most likely to fail, with files which are of relatively low value (programs don't store results in /tmp unless the user specifies as such... so /tmp and /var/tmp have disposable data, as they are "scratchpad" areas. And a single /tmp directory can be shared by multiple hosts via NFS. /var/tmp is for the tmp files that can't be on a shared /tmp.

Poettering is really trying to dumb-down Linux into MS-WINTENDO.