Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Wed, Feb 15, 2012 at 11:32:10AM +0100, Walter Haidinger wrote: > > -------- Original-Nachricht -------- > > > I am using different (from yours) versions of drbd and kernel with similar > > symptoms, so it is not a bug and even expected behavior. By default raid > > is > > rebuild at the maximum possible speed and throttled down when there is IO, > > while drbd also tries to resync at its configured speed ... the load on > > the > > disks in this case may rise above their limits. > > I see. To clarify: I was talking about system load (as shown by uptime > or top), not disk load. > > > I have limited the resync speed for both drbd and the raid in general to > > some lower value than the disks are capable (and leave some for the apps > > too). Because in my case, drbd takes (much) less time to resync, when > > necessary i manually set the raid resync to the minimum possible value > > (may > > even try with 0 as speed_max). Another option is to pause-sync / > > resume-sync of drbd instead of disconnecting. With the above the load is > > still reaching 5-10, but at least the system stays responsive. > > Good idea, thanks! I've limited drbd resync speed, but not for md. > I'll lower dev.raid.speed_limit_max and see if it helps. > > Still, I'm curious why a raid resync on the secondary node drives > up the system load on the primary even while the drbd link is idle. > Maybe the devs can explain this briefly? Don't think bandwidth (idle). Think increased latency. You need to wait longer for writes to be completed -=> increased "load". -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com