[vox-tech] Need Partitioning Advice

[Rick Moen]

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

> Er, right in the bold 3rd paragraph he mentions /boot, he mentioned in in the
> why partition paragraph... twice.  In fact he mentioned /boot as 4th most
> important partition ahead of /tmp, /var, /home, and /usr/local.  He mentioned
> /boot a dozen or so times, and it's in his examples that he lists.
> 
> So what is factually incorrect again?

It's not in his basic recommendation, nor his "How many partitions"
list, nor his desktop recommendation.  The only example he has it in is
"A suggested laptop/desktop configuration" at the end.  You're
characterisation of "strong on /boot" is obviously wrong -- as will be
apparent to anyone who actually reads the page.

But, you know, Karsten has already done his best to set you straight.

Oddly, there are scenarios where a separate /boot still makes some
sense, even on modern hardware where the 1024 logical cylinder BIOS
booting limit no longer applies -- but for the most part, that is (as I
already said) indeed obsolete.

Partitioning needs emerge from the particular situations of specific
systems, always.  Attentive reading of Karsten's page would have told
you he was saying that.  If not, his post _here_ calling your attention
to that fact should have.  ;->


> > And yet a trained monkey can do "df -h" on a similar installed
> > system, to guesstimate the target requirement for the system's
> > projected life.
> 
> Sure, if you have a similar system like that in production, even then
> it seems like a fair number of mistakes are made, like you are Karsten
> occasional reinstalls and use the use.

And yet, this proves in practice to almost never be a problem.

When starting out, you don't get fancy, you observe where space is
needed and how much, and it becomes pretty obvious.  Observe, learn,
apply knowledge gained.  This really isn't difficult.


> IMO as far as maintenance, robustness, and
> sustainability are concerned that many (>= 6) are worse than few (<=4)
> partitions are having to resort to ln -s is particularly evil, ruins
> performance and makes it harder to maintain the machine.

The 11 years of 24x7 service from my server's hard drives (the pair that
were killed eventually by a PG&E power spike, this past April) seem
incompatible with your assertion about maintenance, robustness, and
sustainability.  Just as one data point that is handiest to mind.

Obviously, you move part of a filesystem and symlink it only as a
last-resort move, and you do _not_ do that for performance-sensitive
moves, as fortunately most would not be.

What you would generally eventually then do, in that last-resort
scenario, is rsync-over-ssh the data off to somewhere across a network
for safekeeping, blow away the filesystems in question, remake them at
the desired size, remount, rsync the data back.  That's how we do it in
production.