Re: [PATCH v2] drbd: only send P_PEERS_IN_SYNC for up to 4 MiB in resync progress

Hi Joel,

Thank you for your suggestion!
Based on your suggestions, I made some modifications and sent the v3 version.


Best regards,
zhengbing



 黄正兵
[email protected]










Original:
From：Joel Colledge <[email protected]>Date：2025-12-19 19:13:12(中国 (GMT+08:00))To：zhengbing.huang<[email protected]>Cc：drbd-dev<[email protected]>Subject：Re: [PATCH v2] drbd: only send P_PEERS_IN_SYNC for up to 4 MiB in resync progress> The solution is to ensure that P_PEERS_IN_SYNC within a range of 4 MiB is sent each time,
> and skip the sector where there is no reysnc.

This implementation causes some P_PEERS_IN_SYNC to be sent that are
not necessary. It is still an improvement compared the current
behavior, but it would be good to solve this cleanly while we are
working on this code.

In my test I cause the following sectors to be dirty:
offset 24568 sectors (== 12MiB - 4KiB), size 8 sectors
offset 40960 sectors (== 20MiB), size 8 sectors

I expect P_PEERS_IN_SYNC with offsets:
16384 sectors (== 8MiB)
40960 sectors (== 20MiB)

I observe P_PEERS_IN_SYNC with offsets:
0 sectors
16384 sectors (== 8MiB)
24576 sectors (== 12MiB)
40960 sectors (== 20MiB)

Perhaps the code would be simpler if you handle the case of
potentially calling drbd_queue_update_peers() for the previous
last_peers_in_sync_end position as a separate case?

> +       for (; peers_in_sync_end - peer_device->last_peers_in_sync_end >= PEERS_IN_SYNC_STEP_SECT; ) {

This could be written as a while loop, but maybe it will change anyway
with the suggestion above. Perhaps we don't need a loop at all.
update_peers_for_range() already handles splitting the range up in
4MiB chunks.

Please ensure that your patches pass the checks from the Linux
upstream checkpatch.pl. Some of the lines are too long in this patch.
I know that the current code does not always pass. We are cleaning it
up as we work on it.

Joel