[sclug] Newbie, partitioning 120Gb HDD - recommendations?

Tom Dawes-Gamble tmdg at tmdg.co.uk
Wed Jan 19 08:34:46 UTC 2005


On Tue, 2005-01-18 at 22:57 +0000, Alex Butcher wrote:
> On Tue, 18 Jan 2005, Tom Dawes-Gamble wrote:
> 
> >
> > I think the general advice is that you want root to be fast. But is that
> > the best strategy?
> 
> I'm not sure it is. My gut feeling is that once the system has booted, and
> you have some daemons running, anything worthwhile from / will be cached or
> resident anyway. Assuming you have enough memory (these days, not having
> enough better be for a damn good reason :).
> 

Yep I'd go along with that.

> I'd prefer to put /usr, then /home or /usr/src in the fast zone, saving the
> slower zones for things like /var/spool or general dumping areas (/scratch,
> in my case). Putting /var/spool in the fast zone might be more appropriate
> if the machine is hosting a non-home-Maildir IMAP/POP3 server, though.
> 

Yes thats one way.  However, I personally don't think it makes much
difference.  Mail arrives in a random fashion and assuming you have a
number of users getting similar amounts of mail then IMHO you would be
safe in assuming the head would not in the right place at the right
time.  Thus the seek time would blow away any increase in speed  you
might gain using the faster part of the disk.  The may be a case for
having say /usr/src in the fastest part if you spend your day building
kernels  but even then most of the time is spent dealing with small
files only when you come to write vmlinuz would you gain any time.
Even with an application that can benefit from the improved performance,
I wonder if you would ever recover all the time you spent working out
the optimum layout.

> Because I'm an LVM convert, I've pretty much lost all control over /where/ I
> place filesystems these days. They're all over the disc, literally. :-/
> 

You can still place logical volumes by creating dummy volumes over the
PEs you want to skip or reserve.  But I'm not sure it's worth the
effort.

regards,
Tom.



More information about the Sclug mailing list