Re: Patititioning hard drive
* Mario Vukelic (mario.vukelic@chello.at) spake thusly:
> On Tue, 2001-12-11 at 15:11, Kent West wrote:
>
> > There are two basic reasons for having extra partitions: reliability, and
> > security.
>
> The other day I read that it's /not/ recommended to partition a single
> disk too much, since the kernel would not handle that well: it would
> read/write the partitions alternating, leading to a lot of unnecessary
> head movement and performance degradation.
>
> I'm sort of a control freak too (as far as my computers are concerned)
> and have my disk(s) partitioned for years with for /var, /tmp, /, /home.
> Now I'm deeply worried when I think of all the performance lost ;o). I
> never heard of that kernel problem before, and I don't know if it's
> true. Hopefully someone who knows will comments on that.
When your system switches from reading in a binary from /bin to
writing a pid file in /var, obviously, there'll be head movement.
If /bin sits on one end of the disk, and /var on another, there'll
be more head movement; if the binary and pid file in question live
right next to each other there'll be less head movement. I don't
see anything specific to linux kernel in that.
Ideally, you want to put all files into one big partition in most
frequently used order. (I suspect you could do something like that
on a big iron...) Of course, this assumes that there's no fs cache
and everything lives on the same disk. And that files don't grow.
And a fairly dumb disk with no optimizations on request queues
(well, ok, that depends how much disk i/o you do in the first place;
if requests don't get queued, there's nothing to optimize...)
And so on.
I'm sure in practice you'll get much better performance from buying
several decent (fast, SCSI, etc.) disks and more RAM than you'll get
from re-arranging files and partitions on a single IDE drive. And
even then, if your box does dma transfers and has cycles to spare,
IDE won't be all that bad.
>Anyway, a /var
> and/or /tmp partition won't probably hurt much, /usr and /usr/lib may be
> a different story. OTOH, Debian needs a /big/ /var when upgrading the
> dist, and /tmp at times also needs a lot of space (printing big pix,
> ...), so for a desktop system a 100 MB partition for / and 50 for /boot
> with the rest unpartitioned probably is now bad idea either.
Hmm. More like 5MB for /boot and 10GB for /. A separate partition for
users' data may not be a bad idea, but if you do regular backups that
doesn't really matter.
Dima
Reply to: