Distributed Replicated Block Device (DRBD) development
 help / color / mirror / Atom feed
From: "zhengbing.huang" <zhengbing.huang@easystack.cn>
To: drbd-dev@lists.linbit.com
Subject: [PATCH v2] drbd: only send P_PEERS_IN_SYNC for up to 4 MiB in resync progress
Date: Thu, 18 Dec 2025 21:01:17 +0800	[thread overview]
Message-ID: <20251218130117.907395-1-zhengbing.huang@easystack.cn> (raw)

During the resync process, the range of resync is not continuous.
If the next sync position is very far from the current sync position,
it will cause the same problem as commit: e2d0439f9
("drbd: only send P_PEERS_IN_SYNC for up to 4 MiB when resync finished").

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.

Fixes: bc218ad64640 ("drbd: only send P_PEERS_IN_SYNC every 4MiB")

Signed-off-by: zhengbing.huang <zhengbing.huang@easystack.cn>
---
 drbd/drbd_int.h      |  3 ++-
 drbd/drbd_receiver.c | 21 +++++++++++++++++----
 2 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/drbd/drbd_int.h b/drbd/drbd_int.h
index d92eaaf37..e193de9e8 100644
--- a/drbd/drbd_int.h
+++ b/drbd/drbd_int.h
@@ -1930,7 +1930,8 @@ extern sector_t drbd_partition_data_capacity(struct drbd_device *device);
  * extent shift since the P_PEERS_IN_SYNC intervals are broken up based on
  * activity log extents anyway. */
 #define PEERS_IN_SYNC_STEP_SHIFT AL_EXTENT_SHIFT
-#define PEERS_IN_SYNC_STEP_SECT_MASK ((1UL << (PEERS_IN_SYNC_STEP_SHIFT - SECTOR_SHIFT)) - 1)
+#define PEERS_IN_SYNC_STEP_SECT      (1UL << (PEERS_IN_SYNC_STEP_SHIFT - SECTOR_SHIFT))
+#define PEERS_IN_SYNC_STEP_SECT_MASK (PEERS_IN_SYNC_STEP_SECT - 1)
 
 /* bit to represented kilo byte conversion */
 #define Bit2KB(bits) ((bits)<<(BM_BLOCK_SHIFT-10))
diff --git a/drbd/drbd_receiver.c b/drbd/drbd_receiver.c
index d43f3f98b..2bbf167a8 100644
--- a/drbd/drbd_receiver.c
+++ b/drbd/drbd_receiver.c
@@ -2540,8 +2540,10 @@ void drbd_queue_update_peers(struct drbd_peer_device *peer_device,
 	}
 }
 
-static void drbd_peers_in_sync_progress(struct drbd_peer_device *peer_device, sector_t sector_end)
+static void drbd_peers_in_sync_progress(struct drbd_peer_device *peer_device, sector_t sector_start, sector_t sector_end)
 {
+	sector_t range_end;
+	sector_t peers_in_sync_start = sector_start & ~PEERS_IN_SYNC_STEP_SECT_MASK;
 	/* Round down to the boundary defined by PEERS_IN_SYNC_STEP_SHIFT. */
 	sector_t peers_in_sync_end = sector_end & ~PEERS_IN_SYNC_STEP_SECT_MASK;
 
@@ -2555,8 +2557,19 @@ static void drbd_peers_in_sync_progress(struct drbd_peer_device *peer_device, se
 	if (peers_in_sync_end == peer_device->last_peers_in_sync_end)
 		return;
 
-	drbd_queue_update_peers(peer_device, peer_device->last_peers_in_sync_end, peers_in_sync_end);
-	peer_device->last_peers_in_sync_end = peers_in_sync_end;
+	for (; peers_in_sync_end - peer_device->last_peers_in_sync_end >= PEERS_IN_SYNC_STEP_SECT; ) {
+		/* Ensure send range does not over 4 MiB */
+		range_end = min(get_capacity(peer_device->device->vdisk),
+			(peer_device->last_peers_in_sync_end | PEERS_IN_SYNC_STEP_SECT_MASK) + 1);
+
+		drbd_queue_update_peers(peer_device, peer_device->last_peers_in_sync_end, range_end);
+
+		if (peers_in_sync_start <= range_end)
+			peer_device->last_peers_in_sync_end = range_end;
+		else
+			/* Skip the no resync range */
+			peer_device->last_peers_in_sync_end = peers_in_sync_start;
+	}
 
 	/* Also consider scheduling a bitmap update to reduce the size of the
 	 * next resync if this one is disrupted. */
@@ -2580,7 +2593,7 @@ static void drbd_check_peers_in_sync_progress(struct drbd_peer_device *peer_devi
 	spin_unlock_irq(&connection->peer_reqs_lock);
 
 	list_for_each_entry_safe(peer_req, tmp, &completed, recv_order) {
-		drbd_peers_in_sync_progress(peer_device, peer_req->i.sector + (peer_req->i.size >> SECTOR_SHIFT));
+		drbd_peers_in_sync_progress(peer_device, peer_req->i.sector, peer_req->i.sector + (peer_req->i.size >> SECTOR_SHIFT));
 		drbd_free_peer_req(peer_req);
 	}
 }
-- 
2.43.0


             reply	other threads:[~2025-12-18 13:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-18 13:01 zhengbing.huang [this message]
2025-12-18 16:47 ` [PATCH v2] drbd: only send P_PEERS_IN_SYNC for up to 4 MiB in resync progress Joel Colledge
2025-12-19 11:13 ` Joel Colledge
2025-12-23 11:15   ` ZhengbingHuang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251218130117.907395-1-zhengbing.huang@easystack.cn \
    --to=zhengbing.huang@easystack.cn \
    --cc=drbd-dev@lists.linbit.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox