[DRBD-user] syncer speed

Sebastian Riemer sebastian.riemer at profitbricks.com
Wed Jan 2 11:01:13 CET 2013

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


there is an IO request size bug in < 8.3.14 and < 8.4.2. That version
model doesn't support pushing stuff to linux-stable.

See this for details:




On 24.12.2012 19:00, Digimer wrote:
> On 12/24/2012 05:48 AM, Walter Robert Ditzler wrote:
>> hi to all,
>> is there anyone who has experience in speed allocation for a double 10gbit/s
>> 10gbase bounded with bound type 3?
>> i configured ...
>> ***
>> syncer {
>>     al-extents            31;
>>     rate                     450M;
>> ***
>> ... but get back a copy speed of a 800mb dummy file of 46m/s.
>> any help appreciated :-)
>> happy x-mas,
>> walter.
> First, confirm what speed your network can sustain on it's own. Use
> 'iperf' if you can, it's my go-to tool for network performance testing.
> Next, break out one of the backing storage devices, put a normal FS on
> it (like ext4) and use something like bonnie++ (and be sure to set a
> test size that is 2x your RAM) to test the bare storage maximum
> sustained throughput.
> Once you know how fast they are on their own, take the slower of the two
> and that is the theoretical maximum speed that DRBD will achieve.
> Generally, I set the 'syncer { rate xxM; }' to ~30% of that speed. If
> you set syncer to be too fast, your normal I/O will suffer as the
> background syncing will consume all your available bandwidth. This is
> why the sync rate is set low by default.
> If you set the  'syncer { rate xxM; }' to a speed higher than is
> actually possible, it could actually hurt performance and, possibly,
> stall the sync entirely.
> To be clear;
> The syncer rate is *not* the day to day performance speed. Normal I/O,
> like writing a file to the FS on the DRBD resource, will always go as
> fast as is possible. The syncer rate *only* effects the speed at which
> out-of-sync blocks are copied over when one of the nodes has been
> off-line and blocks changed on the remaining peer,
> digimer

More information about the drbd-user mailing list