lkml.org 
[lkml]   [2002]   [Dec]   [24]   [last100]   RSS-feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
Complete thread (EXPERIMENTAL)
/
DateTue, 24 Dec 2002 09:21:23 -0800
Fromjw schultz <>
SubjectRe: Horrible drive performance under concurrent i/o jobs (dlh problem?)
Digg This
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.ws
		Remember Cernan and Schmitt
\
ISP Services
Valid XHTML 1.0!\ /
Valid CSS! Last update: 2005-03-22 12:31    [W:0.156 / U:0.540 seconds]
©2003-2005 Jasper Spaans