Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
> To test my hypothesis, you'd have to disable the write-back cache. You're right of course. I've done a couple more tests: uname26 hpacucli ctrl=0 ld 2 modify aa=disable dd if=/dev/zero of=foo bs=8192 count=1024 oflag=sync 1024+0 records in 1024+0 records out 8388608 bytes (8.4 MB) copied, 11.9341 s, 703 kB/s 703 kB/s? Ouch! uname26 hpacucli ctrl=0 ld 2 modify aa=disable dd if=/dev/zero of=foo bs=8192 count=8192 oflag=sync 8192+0 records in 8192+0 records out 67108864 bytes (67 MB) copied, 1.21189 s, 55.4 MB/s Seems that at least in our case, disabling the write cache is a very reliable way to obliterate performance. This is with md flushing, disk flushing, and disk barriers re-enabled in DRBD, just to be safe with the inconsistent cache state. Now, for these particular controllers, disabling the BBU automatically disables the write cache. I can't say for sure whether or not they actually do that without going to the colo and yanking the capacitor, but presumably we'd see similarly terrible performance without the BBU. I can't confirm any of this with 8.3.11 unfortunately. But 8.4.1 at least, works as expected on our hardware. ______________________________________________ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email