[vox-tech] (forw) Re: (forw) Re: Need Partitioning Advice

[Rick Moen]

Passing back Karsten's own comments.

----- Forwarded message from "Karsten M. Self" <karsten at linuxmafia.com> -----

Date: Thu, 18 Jun 2009 17:40:22 -0700
From: "Karsten M. Self" <karsten at linuxmafia.com>
To: Rick Moen <rick at linuxmafia.com>
Subject: Re: (forw) Re: [vox-tech] Need Partitioning Advice

Some additional comments, feel free to forward to vox-tech:

on Thu, Jun 18, 2009 at 11:30:56AM -0700, Rick Moen (rick at linuxmafia.com) wrote:
> ----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----
> 
> Date: Thu, 18 Jun 2009 11:27:06 -0700
> From: Rick Moen <rick at linuxmafia.com>
> To: vox-tech at lists.lugod.org
> Reply-To: lugod's technical discussion forum <vox-tech at lists.lugod.org>
> Subject: Re: [vox-tech] Need Partitioning Advice
> 
> Quoting Bill Broadley (bill at cse.ucdavis.edu):

Among the omitted quotes:  that the referenced document dates to 2000.
While it was begun in 2000, it's been continuously updated, most
recently in March of this year.

I also make a point of noting that there's nothing particularly "wrong"
with the One Big Partition school (though root plus swap is still
generally recommended).  

    *** IN BOLD TEXT!!! ***

    *** IN THE THIRD PARAGRAPH OF THE FAQ!!!! ***

I guess you can't please 'em all.

Even swapfiles are largely tenable these days as performance issues have
been addressed.

This and several other comments lead me to believe that the guide wasn't
so much read as imputed....

 
> > * Multiple swap partitions because of limitations on swap size partitions.
> 
> Multiple swap partitions per _spindle_, as mentioned in part of
> Karsten's page, is indeed old hat.  On the other hand, having multiple
> swap partitions of the one-per-spindle variety is just common sense, as
> it improves performance considerably.
 
> > While this is a rather personal preference, many of the ideas that
> > led to the 5-6 partitions as standard operating procedure are gone.
> > Some of those ideas that are no longer true: * file systems that
> > didn't scale to large sizes well
> 
> I can't find anywhere in Karsten's document where he says anything
> about Linux filesystem scaling problems, let alone those being a
> factor in partitioning.  Can you please point it out?  (It's possible
> you weren't thinking of Karsten's page, in that particular, but were
> just citing obsolete concerns generally.)

There actually are some scaling issues above 2TB which I don't address,
though I've started encountering them at work.  These include
both partitioning and filesystem support.

DOS partitioning no longer works above this size, instead, Intel EFI/GPT
must be used.  fdisk can't support >2TB filesystems, so use GNU parted.
And older versions of ext3fs will fail as well (I don't recall the exact
transition point).

 
> > * lack of journals that lead to long fsck times
 
> Only if you mount rw by default, and only on filesystems of significant
> size and complexity.

Actually, both incorrect.

Journals allow bypassing of fsck on most boots.  Journal integrity is
validated, and inconsistent inodes deleted.  However, unless disabled,
once the fsck check interval or reboot/remount count is exceeded, a full
fsck is still executed, and this is strictly governed by disk size.
Worse, fsck time scales poorly as disk sizes increase, an issue kernel
developers have been quite cognizant of.  Read Ted Tso or Val Henson /
Val Aurora on this.  Ext4 is supposed to address this, as will SSD:

http://thunk.org/tytso/blog/2009/02/26/fast-ext4-fsck-times-revisited/
http://lwn.net/Articles/337680/
http://valhenson.livejournal.com/41912.html

While journals speed *boot* times (and greatly assist in ensuring
filesystem integrity), they do nothing for fsck times.
 

> Consider /usr on a server where that is kept mounted read-only except
> during installation/removal of packages.  Why have the overhead of a 
> journal?
> 
> Consider also a /tmp filesystem where you want high performance, and for
> some reason don't want to use tmpfs.  (Maybe you prefer /tmp to be
> persistent between reboots.)  Again, why do you want the overhead of a
> journal on _/tmp_?
> 
> The example of /usr will not lead to long fsck times because it's synced
> at all times (except rare occasions when you remount it rw for package
> operations).
> 
> The example of /tmp doesn't lead to long fsck times because, well, it's
> /tmp -- isn't huge, doesn't have large amounts of stuff in it.

... all of which covers the basic rationale for partitioning:  it allows
you to use appropriate features for different filesystems.
 

> > * Rare/expensive unix systems that ran tons of services and had
> >   shells for users.  Which required protecting services from users
> >   and vice versa.
> 
> Actually, protecting the system from misbehaving processes, and the
> system from the sysadmin, and the system from poor recoverability, are
> rather more the point.  So, for example, the more the root filesystem
> is isolated by having non-essential things be in separate filessytems,
> the more likely you will be able to mount / at boot time despite
> problems that may have arisen in, say, /usr or /var.
> 
> There's a really good reason why system recovery/restore/repair tools
> are all in /bin and /sbin:  That's so they'll not be unavailable if /usr
> is temporarily hosed and cannot be mounted.  Why else do you think those 
> and /usr/bin / /usr/sbin aren't simply merged for simplicity's sake?

I agree strongly with Rick's view here.


> > * Crude partition based backups
> 
> You'd rather provide an explicit and laundry list of directories (that
> must then be maintained), when just adding "-x" (don't cross filesystem
> boundaries) to your rsync command solves that problem entirely?  Really?

Bingo.

 
> > * The lack of online resizing and logical volumes
> 
> Oddly, some of us don't like LVM/LVM2 on account of the avoidable
> complexity those add to a system's architecture, and would rather not
> trust our files to online resizing.
> 
> Ironically for your comment (above), Karsten _does_ mention LVM in a
> laudatory fashion, as an option -- though he doesn't employ it in his
> examples.

Yep.

 
> > * Horrifyingly poor security defaults
> 
> Can you be a few orders of magnitude more specific?
> 
> Defaults of noexec or nosuid on some portions of the tree, e.g., were of
> course not intended to deter anyone who's already cracked root, but
> could prevent both canned attacks from succeeding (if, say, you've been
> caught napping by yet another developed PHP app hole) and can help avoid
> sysadmin mishap.
> 
> Anyhow, Karsten's document wasn't about tips to deal with security
> issues.  Are you asserting that his recommended partitioning strategy
> _hurts_ security?  If so, in which particulars? 

I'll refine that point a bit, if I may speak for the original author....

  - The usual security threat is the operator.  Preventing
    fumble-fingered mistakes is a great way to avoid harm and downtime.

  - Even a stultifyingly low bar can be tremendously effective at
    avoiding common exploit paths.  The exploits are common because the
    low-hanging-fruit preventive measures are so infrequently taken.
    Any time you can eliminate an entire class of exploit avenues, as
    the OpenBSD folks have proven time and again, you're miles ahead.
    Stripping SUID and DEV, and EXEC where possible, is damned simple.

If you can prevent an attacker from creating a lever (device file,
executable, SUID file) somewhere, they're going to have to try that much
harder.  And you'll avoid many of the drive-by / automated hacks.

Naturally, if someone's specifically interested, at all cost, in you,
the picture changes radically.  As always the relevant questions are:

  - What is your threat model?
  - Who is your attacker?
  - What is her attack budget?
  - What is at risk in an attack?  (Access, control, integrity, DoS,
    ...)
  - What reasonable countermeasures / recovery paths are available?

 
> > * ram was so expensive you usually didn't have enough to reasonably buffer
> 
> Oddly enough, my server had a mere 256 MB until this April, not because
> RAM was expensive, but rather because I didn't want to sink _any_ more
> money into a box that was going away, and the migration to the
> replacement box kept being deferred.
>
> But anyway, regardless of how much RAM I have on my servers (and the
> upgrade to the newer machine with 1.5 GB was a big relief, thanks), it's
> a point of pride not to waste it.  I have work for it to do.

I'll note again, from the FAQ text:

    I *very* strongly recommend kernel hacker Martin Pool's essay Is swap
    space obsolete?
    http://sourcefrog.net/weblog/software/linux-kernel/swap.html
 
> > * file systems that often resulted in poor locality, so partitions were
> >   used to keep the head more local when processing a news spool or the like.
> 
> Guess what?  NFS hasn't gone away.  Nor SMB.
> 
> > * Installing 2 or more OSs on a single machine was rare.
> 
> This seems irrelevant:  Although Karsten's page doesn't address that
> case explicitly, I can't see that his recommendations wouldn't apply
> there, pretty much the same.

Wait?  There's an OS other than Debian GNU/Linux?  And nobody told me?

I don't dual boot.

While multi-booting is indeed a justification for partitioning, it's not
one I address or much care for at all (VMs are the way to fly anyway, as
Rick notes).

> Anyway, dealing with multiple OSes per machine through partitioning
> seems quaint, to me, since the development of good VM technology.  My
> experience was always that people thinking they were going to boot back
> and forth between OSes were kidding themselves:  They ended up, over
> time, staying almost entirely in one of the OSes, because shutting down
> and rebooting was too disruptive.
> 
> On the other hand, having, say, a VMware window on your corporate Linux
> laptop running so you can use MS-Outlook for the corporate mail/calendar
> system, and MSIE for some of the less well-designed (e.g.,
> ActiveX-based) intranet sites, is eminently practical.
> 
> > * the lack of device, pty, /proc, tmpfs and other related virtual or temporary
> >   filesystems that help offload the duties and security privs required
> >   of a filesystem.
> 
> Um, /proc is mentioned.
> 
> But all of those are irrelevant to _partitioning_, anyway.  Karsten's
> page is about partitioning strategy.

Bingo.
 
> Anyhow, I'd feel a prize chump if I had my server set up as
> single-filesystem plus swap on quite a few grounds, including
> performance:  Being able to put the swap in the middle of the spindle,
> and the most-visited portions of the file tree on either side, is a huge
> win for keeping average seek time low.  I'd be bloody incompetent if I
> _didn't_ do that.


Peace.

-- 
Karsten M. Self <karsten at linuxmafia.com>        http://linuxmafia.com/~karsten
    Ceterum censeo, Caldera delenda est.



----- End forwarded message -----