Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On 06/21/2012 10:09 AM, Shaun Thomas wrote: > 703 kB/s? Ouch! Interesting. For 8 kB blocks, 703 kB/s means 87 IO/s, or 5272 IO/min. Sounds like a 7200 RPM drive, with some overhead. But now that I'm thinking about this more, there's a flaw in this testing methodology. We don't know if the decrease in performance is because DRBD is asking your RAID controller to flush cache, or if your RAID controller is simply not caching at all. I could, in my environment with a simple SATA drive, make DRBD "safe" by disabling all write caching entirely with something like "hdparm -W 0 /dev/sda". However, there's a big difference between not caching when it's important, and not caching, ever. No caching at all also means I can't take advantage of NCQ. I'm having a hard time thinking of a way to test your RAID controller's behavior that isn't harder than just testing on a regular SATA drive, which has caching semantics that are well known. I don't think there are any means of doing IO from userspace that bypass the pagecache and also don't flush the drive cache (unless they are broken). I'd still really like to hear from a DRBD developer about what the desired behavior of DRBD is. I keep thinking about [1], and it seems pretty clear to me that the position there, that fsync() causes no change in behavior as far as DRBD is concerned, is horribly wrong, and demonstrably not true of MD, LVM, or SATA devices. But that was in 2006; has anything changed since then? [1] http://lists.linbit.com/pipermail/drbd-user/2006-December/006105.html