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?

  • 3
    possible duplicate of /usr/bin vs /usr/local/bin on Linux
    – jasonwryan
    Mar 24, 2014 at 21:45
  • I'm well aware of what they're used for. I'm really more interested in why people (I think Fedora did that) chose to merge everything into /usr/bin rather than the other way around. Obviously, it's not really necessary to follow the original intention of /bin and /sbin anymore. At least not on the desktop. I was going to design my own, Debian based distro and this is something I have been pondering with. Just seems more elegant to me to have all applications in /bin.
    – user237251
    Mar 24, 2014 at 21:51
  • I think Fedora did that Fedora symlinked /bin, /lib, /lib64 and /sbin to /usr/bin, /usr/lib, /usr/lib64 and /usr/sbin. /bin and /sbin are still separate.
    – Dennis
    Mar 24, 2014 at 23:56

4 Answers 4


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.

  • 1
    1. What do you mean by "vendor"? 2. But there is no separation between "vendor-supplied OS resources" and machine-specific resources. 3. "And clutter the root filesystem" - on the contrary. Instead of having redundant folders on / and in /usr, we would just have folders under /, and no more arbitrary /usr prefix for files which in the far past were on some separate disk.
    – einpoklum
    Apr 6, 2022 at 19:32
  • @einpoklum you're 8 years too late to make a case against the /usr merge. I agree the concept of a /usr dir shared between multiple systems or even seperate partitions from / is an outdated idea, but it wasn't yet in 2014.
    – jordanm
    Apr 6, 2022 at 20:17
  • @jordanm With todays clustered, networked, and virtualized environments, it it more up-to-date than ever. Atomic updates of signed, read-only system partitions are also on the rise.
    – Bachsau
    Mar 5 at 14:02
  • @einpoklum etc, home, var and srv are not vendor-supplied, i.e. not really part of the distribution.
    – Bachsau
    Mar 5 at 14:09
  • @Bachsau: Some of /etc is vendor-supplied; but regardless - I'm not sure how your comment bears on mine.
    – einpoklum
    Mar 5 at 18:22

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.

  • Thanks for that info. I was actually just trying to symlink /sbin but ended up with a system that was no longer able to boot on it's own ("command /sbin/init not found"). Is this because of the symlinks inside /sbin? I set up a directory inside /bin called "utils", copied all files from /sbin there (using the -rp flag), deleted /sbin and set up a symlink called sbin, pointing toward /bin/utils.
    – user237251
    Mar 31, 2014 at 9:37
  • 1
    Here's a guess: /sbin/init is itself often a symlink. "init" is the canonical name of the first process; it's the only process actually started by the kernel and cannot be killed, so it is always PID 1 (have a look at, e.g., ps -lp 1). systemd (fedora) and upstart (ubuntu) are new-fangled init systems that symlink their binary from /sbin/init so the kernel can find it. On my fedora here, that link is literally ../lib/systemd/systemd, so if you moved it to /bin/utils the link would be broken (that's not the only symlink in /sbin, either).
    – goldilocks
    Mar 31, 2014 at 12:30
  • Thanks. Got it now. For some reason, I was approaching the whole thing from the wrong side. I just generated a list of all symbolic links found on the system. Something that also happened to slightly clear up my earlier confusion as to why people would merge into /usr/bin, rather than the other way around. It's simply way more straight forward, as one doesn't need to care about breaking third party packages.
    – user237251
    Apr 1, 2014 at 9:14

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

  • 1
    Why "unfortunately"? Larger filesystems can now be loaded earlier in the boot sequence, nullifying one of the biggest reasons to split /usr into a separate hierarchy to begin with.
    – jayhendren
    Dec 20, 2016 at 22:53

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.

  • You've missed the part about using an initramfs for all the important boot-related stuff. Then you can just put both / and /usr on the durable non-flash drive. The rest of this appears to be just a senseless rant.
    – ilkkachu
    Feb 20, 2022 at 22:35
  • Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.
    – Community Bot
    Mar 1, 2022 at 13:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .