Subject: Re: consensus on systinst partitioning
To: NetBSD-current Discussion List <current-users@NetBSD.ORG>
From: Greg A. Woods <woods@weird.com>
List: current-users
Date: 06/11/2003 14:11:02
[ On Wednesday, June 11, 2003 at 19:34:03 (+0200), Manuel Bouyer wrote: ]
> Subject: Re: consensus on systinst partitioning
>
> On Mon, Jun 09, 2003 at 05:33:18PM +0200, Wojciech Puchar wrote:
> > >
> > > You should also know that there's a performance disadvantage to having
> > > multiple active partitions on the same disk.
> > 
> > is it really true?
> > 
> > it was true (with much difference) with linux at least 2.2.* kernels
> 
> I don't think it's true for *BSD. I didn't run any tests but I can't see
> why this would make a difference.

It's impossible to say whether or not it would make any difference
without knowing what load the machine is working with and what other
disks and partitions might also be in use for the same workload.

However if the root disk has any sizable swap partition then a separate
/usr will potentially require even more and longer seeks if the workload
requires frequent access to both the small root partition and the /usr
partition, each of which are always by default on opposite sides of the
swap partition.  I.e. in this case a separate /usr will be slower,
especially if /home and /var are also both involved in the workload and
they are also both on the same spindle.

It's too bad NetBSD's disk drivers are not a little better intrumented
to allow for collection of inforation about all I/O offsets and
extents.  It's so much easier to demonstrate these problems with visual
aids!  :-)

Back in the old days with very slow disks it was usually easy to show
quite a significant improvement in performance after re-partitioning
following an analysis of actual real-world activity with "sadp".  Of
course in those days the driver knew exactly when it was moving the disk
heads and how far it was moving them so you didn't have to guess about
when multi-track seeks occurred based on the offset from the end of the
last I/O.  I've been reading that it's possible to analyze a disk and
determine the track extents quite precisely though.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>