On Wed, 27 Feb 2013, James Harper <[email protected]> wrote: > > Last time I tried DRBD it was killing my systems. It seems that the > > default configuration for DRBD is to reboot a node if certain failure > > conditions occur - which can be triggered by network problems. I never > > managed to get it to stop doing that. > > There was a debian bug against those default options for exactly the > reasons you noted, unless it was an actual code bug and not a default > configuration bug that you ran in to?
It was an issue of the default configuration that was hard coded into the utilities or the kernel (can't remember which). > > http://etbe.coker.com.au/2012/02/08/more-drbd-performance-tests/ > > > > Also in my tests DRBD when the secondary isn't connected gave > > performance > > that's suspiciously similar to the performance of a non-DRBD system with > > Ext4 > > mounted with the barrier=0 option. Presumably this means that data on a > > DRBD > > system will be at the same risk as with barrier=0 on a power failure. > > I'm looking at either using bcache or moving the metadata to an ssd to try > and avoid these performance problems. > > drbd barrier and flush are configurable, and there are lots of warnings > about turning them off. If you read my above blog post you'll notice that default Ext4 performance was 1663, Ext4 barrier=0 was 2875, and a default configuration of DRBD with the secondary disconnected was 2409. I conclude that the data-loss protection that barriers offer resulted in a performance drop from 2875 to 1663 and that the use of DRBD by restoring the performance to 2409 reduced that protectio0n. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ _______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
