[conspire] Partitioning revisited briefly
rick at linuxmafia.com
Wed Oct 13 20:03:27 PDT 2010
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/),
and 'man 7 hier'.
Some aims people try to advance:
o Protecting the root FS from effects of various mishaps affecting other
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
o Separate subtrees that are on redundant storage from those that
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
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:
(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.
More information about the conspire