Guys, we're all concerned about "seek times" as they are quite
significant compared to the read times. A disk capable of 5Mb per
second can do about 200k - 400k in random-reads.
About 6 years ago, I decided that "fsck" was taking too long, and I
rewrote it to use the elevator algorithm. (as it is a single task,
waiting for every IO to complete, the kernel elevator algorithm didn't
have a chance to do its work: at most one IO request in the queue at
any time).
The result was less than 5% improvement.
Intuitively the elevator algorithm is pretty important. In practise it
isn't all that important:
-- Even During heavy IO there is not often more than a few threads
doing the IO, so the list of IOs that can be rearranged is not
significant.
-- The parameters for modern disks make things less profitable. My first
harddisk had a stepper motor for head-position that did around 1200
steps per second seeking 10 tracks takes 10 times longer than one track.
And a 100 tracks takes ten times longer than that. Modern disks seek
track-to-track in a few milliseconds, and do the whole disk in under
twenty. So fetching 20 random blocks in-order is going to be just
a few milliseconds faster than just fetching in the random order.
Roger.
-- ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * Never blow in a cat's ear because if you do, usually after three or * * four times, they will bite your lips! And they don't let go for at * * least a minute. -- Lisa Coburn, age 9- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/