[DRBD-user] write performance issues

Phil Stoneman pws at corefiling.com
Mon Jul 11 16:21:52 CEST 2011

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

On 11/07/11 15:13, Mark Dokter wrote:
> On 07/10/2011 07:30 PM, Phil Stoneman wrote:
>> I've seen a similar thing with small writes, and for me, using
>> no-disk-barrier and no-disk-flushes solved the small write performance
>> issue. Hope that helps! :-)
>  From [1]:
> "Unfortunately device mapper (LVM) might not support barriers."
> Although, cat /proc/drbd states
> 3: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
>      ns:0 nr:46983440 dw:46983440 dr:0 al:0 bm:2863 lo:0 pe:0 ua:0 ap:0
> ep:1 wo:b oos:0

I think that LVM that comes with recent kernels support barriers, which 
is why you're seeing this.

> Furthermore, my 3ware RAID controllers do not have a BBU installed and I
> read that it's not recommended to use no-disk-barriers  and
> no-disk-flushes in this case. The servers are connected to a quite large
> ups tough. Does that suffice?

 From what I understand, the main risk of not using barriers is that 
when drbd thinks something's written to disk, it might not actually be. 
And that's possibly not great - but to me, it doesn't seem any worse 
than using a SATA disk normally with the internal disk write ccache.
Anyway, if you have a UPS which is configured to gracefully shut your 
machines down on power loss, it should have approximately the same 
effect as having a BBU.

Or, to put it another way: I have good and regularly tested backups; the 
small risk of losing a bit of data on writes is more than offset by the 
massive speed benefit that no-disk-barrier and no-disk-flushes gives me.

You can see my previous discussion on this here:



More information about the drbd-user mailing list