[vox-tech] Need Partitioning Advice

[Rick Moen]

Quoting Bill Broadley (bill at cse.ucdavis.edu):

> 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.)

> * 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.

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.


> * 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?

> * 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?

> * 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.

> * 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.

> * 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? 

> * 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.

> * 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.

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.

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.