On Tue, Dec 24, 2002 at 10:18:52AM +0100, Roy Sigurd Karlsbakk wrote:
> >SHORT ANSWER: Segregating partitions reduces seek time. Period.
> >
> >LONG ANSWER: Reads and writes tend to be grouped within a partition.
> >For
> >example, if you're starting a program, you're going to be doing a lot
> >of
> >reads somewhere in the /usr partition. If the program uses temporary
> >files,
> >you're going to do a lot of reads & writes in the /tmp partition. If
> >you're
> >saving a file, you're going to be doing lots of writes to the /home
> >partition. Hence, since most disk accesses occur in groups within a
> >partition, preference should be giving to reducing seek time WITHIN a
> >partition, rather than reducing seek time BETWEEN partitions.
>
> keep in mind that only around half of the seek time is because of the
> partition! Taking an IBM 120GXP as an example:
>
> Average seek: 8.5ms
> Full stroke seek: 15.0ms
> Time to rotate disk one round: 1/(7200/60)*1000 = 8.3ms
I'm afraid your math is off.
The rotational frequency should be 7200*60/sec which makes
for 2.31 us which would produce an average rotational
latency of 1.16us if such a condition even still applies.
My expectation is that the whole track is buffered starting
from the first sector that syncs thereby making the time
rotfreq + rotfreq/nsect or something similar. In any case
the rotational latency or frequency is orders of magnitude
smaller than the seek time, even between adjacent
tracks/cylinders.
If the the stated average seek is 50% of full stroke and not
based on reality then 76% of the cost of an average seek is
attributed to distance and likewise 87% of the cost of a
full. Based on that i'd say the seek distance is a much
bigger player than you are assuming. If it weren't the
value of elevators would be much less.
>
> Then, the sector you're looking for, will, by average, be half a round
> away from where you are, and thus, giving the minimum average seek time
> 8.3/2 = 4.15ms or something like half the seek time. Concidering this,
> you may gain a maximum <= 50% gain in using smaller partitions.
>
> btw. anyone that knows the zone layout on IBM drives?
Having chimed in i'll also mention that having the
filesystems right-sized and small should produce better
locality of reference for multiple files and large files
given the tendency of our filesystems to spread their
directories across the cylinders. One big filesystem is as
likely to have the assorted files spread from one end of the
disk to the other as you will get with several smaller ones.
Witness the discussions that introduce the orlov allocator
to ext[23].
As for the repartitioning when a filesystems outgrows its
partition that is reason #1 for lvm. Care should be taken
though because lvm can also destroy locality through
discontinuous extent allocation.
-- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.wsRemember Cernan and Schmitt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Dec 31 2002 - 22:00:07 EST