[DRBD-user] DRBD fsync() seems to return before writing to disk

Phil Frost phil at macprofessionals.com
Thu Jun 21 18:35:12 CEST 2012

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




More information about the drbd-user mailing list