[conspire] Partitioning revisited briefly

Wed Oct 13 20:30:48 PDT 2010

Rick Moen wrote:
> 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.
> 
> 
> _______________________________________________
> conspire mailing list
> conspire at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/conspire
> 
> 
Thanks Rick, for the useful explanation.
I'll be referring to that, I'm sure, well into the future.

-- 
Mark Weisler
PGP Key ID 68E462B6  http://pgp.mit.edu:11371/
PGP Key fingerprint  87D5 A77B FC47 3CC3 DFF0  586D 23FF F8B4 68E4 62B6