l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
October 7: Social gathering
Next Installfest:
TBD
Latest News:
Aug. 18: Discounts to "Velocity" in NY; come to tonight's "Photography" talk
Page last updated:
2009 Jun 24 11:57

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Need Partitioning Advice
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Need Partitioning Advice



Quoting Bill Broadley (bill@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.
_______________________________________________
vox-tech mailing list
vox-tech@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox-tech



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.