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: http://article.gmane.org/gmane.comp.linux.drbd/21997 http://article.gmane.org/gmane.comp.linux.drbd/22056 Phil