Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
2015-06-18 16:39 GMT+02:00 Robert Altnoeder <robert.altnoeder at linbit.com>: > On 05/28/2015 05:05 PM, Ben RUBSON wrote: > >> So, >> >> I played during hours with the dynamic resync rate controller. >> Here are my settings : >> >> c-plan-ahead 10; //10ms between my 2 nodes, but minimum 1 second >> recommended here : >> https://blogs.linbit.com/p/128/drbd-sync-rate-controller/ > > "c-plan-ahead 10" equals 1 second (the unit is tenth of seconds). > > You can try to decrease that value further, because it makes the resync rate > controller > somewhat more aggressive, and that may effectively increase the resync rate > somewhat. > However, there is no guarantee that this will improve your resync rate > significantly, > because that is a side effect rather than a feature. Yes I tried, but it did not help. >> Well, I'm a little bit lost, I can't achieve to get resync with a >> minimum rate of 400M when there are application IOs... >> >> Here, Lars says : >> http://lists.linbit.com/pipermail/drbd-user/2011-August/016739.html >> The dynamic resync rate controller basically tries to use as much as >> c-max-rate bandwidth, but will automatically throttle, if >> - application IO on the device is detected (READ or WRITE), AND the >> estimated current resync speed is above c-min-rate >> - the amount of in-flight resync requests exceeds c-fill-target >> >> However, does DRBD throttle application IOs when resync rate is lower >> than c-min-rate ? > > No, it does NOT throttle application IO. > > What c-min-rate does, is: > IF the backend device has significantly more > traffic going on than can be accounted for by > the traffic caused by the resync itself, > AND the current resync rate is greater than > c-min-rate, the resync will be throttled > in order to prioritize application IO over > resync IO. > > However, if the resync rate is already less than > c-min-rate, then this feature does NOT throttle > application IO to prioritize resync IO over > application IO > (actually, in the case that the resync rate is > less than c-min-rate, this feature does nothing) Understood, thank you for this clear explanation ! What would be great then is to have a sort of "force-sync-min-rate" option. We would then be able to specify for example "force-sync-min-rate 400M". Application IO would then be throttled to prioritize resync IO. In my DRBD use case, being uptodate, so in other words resync, is the top priority. For security reasons, it is much more important than throughput production application can achieve. Could we think about such an option ? Would be really interesting to improve security / DRBD resilience. Anyway, thank you very much for your answer Robert ! Best regards, Ben