Re: [Ext2-devel] disk throughput

[Jeremy Fitzhardinge <jeremy@goop.org>]

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