[conspire] Partitioning revisited briefly
mark at weisler-saratoga-ca.us
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
> 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
> 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:
> (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
Thanks Rick, for the useful explanation.
I'll be referring to that, I'm sure, well into the future.
PGP Key ID 68E462B6 http://pgp.mit.edu:11371/
PGP Key fingerprint 87D5 A77B FC47 3CC3 DFF0 586D 23FF F8B4 68E4 62B6
More information about the conspire