[conspire] Partitioning revisited briefly

[Rick Moen]

Herein, I will aim to give background information about *ix partitioning
to Darlene in particular, as she asked about it in September.  Darlene
tends to use various desktop boxen.  One of the reasons partitioning
choices are inherently and endlessly debatable along multiple axes of
difference of view is that people partition mass storage for machines
serving diverse functional roles -- not to mention with diverse hardware
contents and with diverse ideas about what to accomplish.

Therefore, one place to start is to list a few of the things people
sometimes choose to emphasise, i.e., what problems they deem worth
solving, and then trace out how partitioning can help those goals.

Nick already aired his view in a 2010-09-06 post where he lead with
conclusions and a some rather dismissive characterisations of about
people applying approaches different from what he recommended.  Look it
up in the archives if interested.

(This message is _not_ an argument for any particular partition scheme,
-- except, below, where it pleads for avoiding complexity you're not yet
sure you need  -- even though the tradition of ritual verbal combat on
this subject is sufficiently hallowed that probably someone will try to
argue with it as if it were.)

Basic reading, by the way, should include FHS (http://www.pathname.com/fhs/),
http://www.intelligentedu.com/linux_system_administration_course/ch03s02.html ,
and 'man 7 hier'.



Some aims people try to advance:

o  Protecting the root FS from effects of various mishaps affecting other
   filesystems.
o  Separating variable portions of the tree from fixed portions.
o  Separating network-sharable from non-sharable data (relevant only on
   large-ish networks of *ix machines.
o  Separating locally-managed from distro/system-managed subtrees.
o  Avoiding excess system complexity and reducing the risk of
   reaching 100% full in any FS.  (This is a reason to shun excess
   partitions, and should be weighed heavily and carefully.  If
   you don't have a compelling reason to make something separate,
   err strongly on the side of simplicity.  When you have actual
   compelling need for splitting filesystems, the need and its
   justification should be obvious.)
o  Separate subtrees under quota or system accounting from those that
   aren't.  (This criterion is widely considered quaint, and is also
   pretty much entirely specific to large-ish multiuser systems.)
o  Use faster mass-storage devices wisely, by putting the most-used
   data on it.  (There's more to it than that, but I'm not going to
   engage in a detail war with all the local obsessives.)
o  Separate subtrees normally kept read-only from those normally
   kept read/write.  Note that one may forego filesystem journals
   on the former and thus keep them simpler.
o  Separate parts of the subtree having different mount flags from
   each other, e.g., noatime, noexec, nosuid, nodev, and so on.
o  Order subtrees physically so as to (you hope) reduce the average
   disk seek distance and wear on magnetic media.  (Obviously, this objective
   does not apply on SSD and similar head-free media.)
o  Split swap space between physical drives (in cases where you have
   multiple physical drives and having swap on more than one makes
   sense generally).
o  Separate subtrees that are on redundant storage from those that
   aren't.
o  Support multibooting (ugh!).

The above is necessarily a little vague and hand-wavey, because
each point really needs several pages of detail and illustration.
In particular, in general it doesn't really get into _why_ people would
want to advance those aims -- and you will doubtless hear loud arguments
that particular of them are silly, obsolete, pointless, etc.  (Once
again, I am not arguing.  Those who wish to violently attack a position
I have not advanced will nonetheless win the global internetz, and can
has cheezburger.)

The reasons for them often have to do with anticipating and disarming
threat models.  Let's take 'separating variable portions of the tree
from fixed portions' as an example.

Anyone who's run *ix for a while has hit 100% disk at some point.
This can be a big problem, especially if you do it with root authority
and thus use up filesystem reserve space.  Bad.  That runaway cronjob or
accidental overnight wget fetch of a 200GB archive file can cause a
cascade of other problems.  But if, say, /var is its own partition and
that alone hits 100%, the effects are contained and minimal.  On
even a server system (which has more going on than a single-user box),
it's obvious which subtrees are prone to overflowing:  /var, /home,
/tmp, and sometimes /usr/local, and that's it.

My own server's current partitioning scheme -- which includes obsolete
features I will lose eventually -- makes a stab at some of the bullet
items.  Here are four example tidbits:



(1) /usr is its own filesystem.  From /etc/fstab:
/dev/sda9       /usr            ext2    nodev,ro        0       2

It's ext2 because it's normally read-only.  (Why have the added
complexity of journaling where it produces no benefit?)  Being
read-only, you're less likely to screw it up through casual mishap,
and also less-smart security threats such as network worms might
be foiled by being unable to write files.

The obvious objection is that needing to continually remount rw just to
do any package operation, and then remount ro after, is annoying.  So,
you automate via apt hooks.  How to do that has been detailed a number
of places including here:
http://lists.debian.org/debian-devel/2001/11/msg00212.html
http://www.mail-archive.com/debian-user@lists.debian.org/msg316812.html


(2) Swap is split between two physical hard drives, for performance.
Again, from /etc/fstab:

/dev/sdb8       none            swap    sw
/dev/sdc8       none            swap    sw

The Linux mass-storage subsystem will intelligently divide swap access
to maximise performance.


(3) Speaking of performance, on either side of the swap partition is
a subtree estimated to be subject to heavy seek activity:  /var/spool
(/dev/md2) just before swap and /home (/dev/md3) just after.


(4) And, just for something refreshing, a measure taken specifically to
_not_ have a partition, and in fact sort of an antipartition:

$ ls -l /opt
lrwxrwxrwx 1 root root 14 Mar  4  2008 /opt -> /usr/local/opt

I've always considered the rationale for /opt (see FHS) to be dumb to
begin with, and also redundant to that of the already extant subtree
/usr/local.  So, I made /opt a symlink to its own little ghetto within 
the /usr/local tree, such that it's not a nuisance and doesn't clutter
up the root filesystem.

(Bear in mind that any symlink achieves its convenience at the cost of 
a performance hit (extra dereference) and the possibility of being
mislead by a broken dangling link, if the referent goes away.  I
expect to use /opt as little as humanly possible, so the double lookup
is of little concern.)


These are just a few of the _sorts_ of things that can be done with a
partitioning scheme that flows from a thought-out local policy.