[conspire] fyi: Understanding the bin, sbin, usr/bin , usr/sbin split

Rick Moen rick at linuxmafia.com
Fri Feb 3 15:21:40 PST 2012


Quoting Tony Godshall (tony at of.net):

> > I sincerely apologise if I confused the hell out of anyone.
> 
> You confused only briefly and overall I'd have to say you have bonus
> deconfusion karma points to spare.

OK, good.  

To review:  Those people lately saying 'there is no longer any
reason for subtree [foo]' are generally mistaken out of ignorance and
failure to pay attention.  You should particularly suspect that when 
you hear bullshit like 'That only mattered back in the days of small
hard disks' and 'We don't usually need to NFS-mount /usr, any more'.

Lately, that ignorance and failure to pay attention has been almost a
core specialty of the freedesktop.org/GNOME people.  They've progressed
from their 'We won't fix our bugs preventing our system tools to work
properly when /usr is on a separate filesystem' of a few years ago to
their current 'because we think separate filesystems are dumb, we
propose to get rid of /bin' -- with further snippage likely (/sbin,
/lib) because they simply cannot understand the _real_ reasons some
subtrees exist, and are too arrogant to ask.

They really ought to understand that there are a _whole_ lot of reasons
for specific partitioning strategies other than 'Long ago, people
suffered from too-small hard drives, but that's all obsolete, now.'  
They include:

o The admin might want to put highly dynamic data that is non-essential
  (like most of /var) on ext2 with noatime, for performance.
o The admin might want to leave /usr normally read-only 
  for protection against mishap (and on ext2) .
o The admin might wish to group most-visited parts of the system tree
  on either side of swapspace, to minimise hard drive head seek 
  distance, seek time, and drive wear.
o The admin might wish to keep the bootable system core (root fs
  with /sbin, /bin, /etc, and /lib) on a small, mostly static 
  filesystem so it's less likely to get clobbered by any process
  that impairs a more-dynamic one like /home or /var.
o The admin might wish to use custom mount options (noatime, nosuid,
  nodev) either for performance or to protect against mishap and 
  to foil the less sophisticated sorts of automated system attack tools.

Ye olde One Big Dumb Partition approach is perfectly OK most of the
time, but that size does not fit all.





More information about the conspire mailing list