Juan writes:

quoted text
>>I have run iozone v. 1.16, a disk benchmark, on my system; I have
>>a 386SX25 CPU, 4MB RAM, and two 65MB RLL hard disk drives.  When
>>(as the documentation suggests) I use a test file larger than the
>>cache, iozone telss me that the effective writing speed is approxi-
>>mately 315,000 Bytes per second, and the reading speed approximately
>>53,000 Bytes per second.

Eric replies:

quoted text
>       The size of the disk block that you are using makes a big difference
>in the speed of reads.  If these numbers are for 512 byte reads, it would not
>surprise me very much.  On the other hand, if this were for 8192 byte reads, I
>would be quite surprised.

I don't understand this slow behavior.  I am going to describe my
understanding of the situation, and perhaps somebody could read over
my explanation an point out where the mistake (or missing piece) is.

I would imagine that if iozone were performing lots of "read(fd, buf, 8192)"
calls, then it would effectively cause this behavior:

    * iozone calls read(fd, buf, 8192)
    * kernel context-switches in.
    * kernel fetches a disk page (8192) bytes from disk into cache.
    * kernel copies 8192 bytes from cache into user buffer.
    * iozone context switches back in.

repeat as necessary.

I would imagine that if iozone were using a smaller block size, say 4096,
then this is what would happen:

    * iozone calls read(fd, buf, 4096).
    * kernel context-switches in.
    * kernel fetches a disk page (8192) bytes from disk into cache.
    * kernel copies 4096 bytes from cache into user buffer.
    * iozone context switches back in.
    * iozone calls read(fd, buf, 4096).
    * kernel context-switches in.
    * kernel copies 4096 bytes (already in cache) into user buffer.
    * iozone context switches back in.

repeat as necessary.

In other words, the smaller block size results in more context-switch
overhead, but not more disk IO.  That wouldn't slow things down by an
immense factor, unless interleave came into play: if the second disk
read were even a moment too late, the disk would have to "go around"
again.

That explanation is no good though, since changing the interleave
to 2:1 would have fixed the problem.  (Unless iozone were using a
VERY small buffer size, say 16 bytes - in that case, the number of
context switches might add up to quite a lot).

So what am I missing?

Although neither Juan or Eric said it explicitly, I suppose that the
read/write speed difference is supposed to be caused by the write-back
cache's tendency to cluster writes, much like read-ahead has the
effect of clustering reads?  Right?