I've done another series of benchmarks, measuring time in seconds to write 915 MB. (That is equivalent to 20 stars of output by blockdev-wipe. "n/a" values simply haven't been measured.) I've tried two different settings for speed_limit_min:
time0: speed_limit_min=0 time1: speed_limit_min=1000 kB/s (default setting) In both cases, speed_limit_max was set to a very large number. bsize | time0 | time1 7.9M 23 n/a 4M 23 n/a 2M 24 n/a 1M 24 22 512k 33 32 256k 52 52 128k 84 92 64k 148 164 32k 272 n/a 16k 472 n/a The numbers seem to indicate that block size is much more important than the raid/speed_limit settings. An interesting pattern emerges, when translating the "time0" numbers into blocks per second: bsize | blocks/s 7.9M 5 4M 10 2M 11 1M 38 512k 55 256k 70 128k 87 64k 99 32k 108 16k 124 It's difficult to coax the drives into more than ~100 sync'ed writes per second, which is nicely consistent with an access time of a bit less than 10ms that one would expect for a 7600rpm drive. What I take away from this: For optimal performance, the frequency of syncs should be kept low, probably well below 50 Hz, ideally as low as possible. I'd be in favour of removing them altogether, but there were some OOM issues seven years ago that were fixed by adding them. Does anybody know whether bug 381135 still applies with today's kernels? In any case, I'd suggest to go at least for 1M block size, even if just to reduce the amount of system calls. (Currently, the buffer in blockdev-wipe is placed on the stack, so anything above 7.9M block size results in a segfault on amd64. I don't know about the stack sizes of other architectures, but anyways, it is bad style to use the stack for large allocations, so I'll move the buffer to the heap, unless somebody objects.) Cheers, Thiemo
