Re: [Ext2-devel] disk throughput

Jeremy Fitzhardinge
2001-11-09T08:49:38Z

On Thu, 2001-11-08 at 22:08, Andrew Morton wrote:
> How do you avoid aftifacts from Linux caching with this test?

Randomly seeking around a 40G disk isn't going to give the caching much
to work with (that was on a 256Mbyte machine). Also, I tried it with
raw devices, but it made no difference to the measurements.

> > I found the random seeking was the only way I could get reasonable
> > numbers out of the drive; any of the ordered patterns of the form "OK,
> > lets measure N block seeks" seemed to be predicted by the drive and gave
> > unreasonably fast results.
> >
>
> But we *want* unreasonably fast results! We need to understand
> this device-level prediction, then decide if it's sufficiently
> widespread for us to go and exploit the hell out of it.
>
> Have you any ideas as to what's happening?

Not really. I wanted results which at least confirm the simple model of
how the disk works. When I did deterministic seeks, it was something
like:

for(n = 0; n < disksize/2; n += about_a_cylinder) {
seek(n);
read();
seek(disksize-n);
read();
}

I suspect that the drive was partitioning its cache and using lots of
readahead to satisfy the reads at either end of the seek. I was trying
to work around that by making the n increment large enough, but it
didn't seem to work. Maybe the drive was being extra special clever, or
maybe I miscalculated the cylinder size. Or maybe I just happened to be
hitting a rotational sweet-spot.

For this kind of test, it would be interesting to know what differences
there are between read and write. In principle the drive could start
writing a track anywhere it wants so long as it has enough to write the
whole thing. That would automatically make it get the track-track skew
right...

J