Re: raw/block device disc troughput

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>      dd if=/dev/zero od=/dev/[r]sd0b bs=nn, count=xxx.

(I've been assuming od= should be of=)

> The block device will cause readahead at the OS layer.

I thought of that too, but didn't mention it, because it's not
relevant.  dd isn't reading from the disk; it's writing to it.

> I suspect that if you double-buffered at the client application layer
> this effect might disappear,

I suspect this is a significant effect.  I was once using dd to copy
from one disk to another, and both drives happened to have activity
lights on them.  Watching each drive wait for the other convinced me dd
is an inefficient way to do that.  I built a program that uses two
processes, one reading and one writing, with a large chunk of memory
shared between them for buffer space.  Disk-to-disk copies (not on the
same spindle) got significantly faster. :)

In this case, dd has to block after each disk write to wait for its
buffer to be (unnecessarily, as it happens, though it can't know that)
zeroed for the next write.  This both imposes additional delay and
enforces a lack of overlap between each write and the next.

I speculate that the cooked device helps because it means that dd's
write finishes when the bits are in the buffer cache, rather than
waiting for them to hit disk.  Flushing from the buffer cache to the
disk then (a) gets overlapped with zeroing memory for the next cycle
and (b) allows writes to adjacent disk blocks to be collapsed as they
get pushed from the buffer cache to the drive.  Unless the host is
unusually slow, writing to the disk will be the limiting factor here,
meaning the buffer cache will have a large number of writes pending, so
coalescing writes is plausible, even likely.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B