Linux-Raid Archives on lore.kernel.org
 help / color / Atom feed
From: Zhao Heming <heming.zhao@suse.com>
To: linux-raid@vger.kernel.org, jes@trained-monkey.org
Cc: Zhao Heming <heming.zhao@suse.com>,
	xni@redhat.com, lidong.zhong@suse.com
Subject: [PATCH] super1.c: avoid useless sync when bitmap switches from clustered to none
Date: Tue,  2 Feb 2021 21:53:41 +0800
Message-ID: <1612274021-21899-1-git-send-email-heming.zhao@suse.com> (raw)

With kernel commit 480523feae58 ("md: only call set_in_sync() when it
is expected to succeed."), mddev->in_sync in clustered array is always
zero. It makes metadata resync_offset to always zero.
When assembling a clusterd array with "-U no-bitmap" option, kernel
md layer "mddev->resync_offset == 0" and "mddev->bitmap == NULL" will
trigger raid1 do sync on every bitmap chunk. the sync action is useless,
we should avoid it.

Related kernel flow:
```
md_do_sync
 mddev->pers->sync_request
  raid1_sync_request
   md_bitmap_start_sync(mddev->bitmap, sector_nr, &sync_blocks, 1)
    __bitmap_start_sync(bitmap, offset,&blocks1, degraded)
      if (bitmap == NULL) {/* FIXME or bitmap set as 'failed' */
        *blocks = 1024;
        return 1; /* always resync if no bitmap */
      }
```

Reprodusible steps:
```
mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sd{a,b}
mdadm -Ss
(in another shell, executing: watch -n 1 'cat /proc/mdstat')
mdadm -A -U no-bitmap /dev/md0 /dev/sd{a,b}
```

Signed-off-by: Zhao Heming <heming.zhao@suse.com>
---
 super1.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/super1.c b/super1.c
index 19fe6f5..92047d5 100644
--- a/super1.c
+++ b/super1.c
@@ -1318,6 +1318,8 @@ static int update_super1(struct supertype *st, struct mdinfo *info,
 			memcpy(bms->uuid, sb->set_uuid, 16);
 	} else if (strcmp(update, "no-bitmap") == 0) {
 		sb->feature_map &= ~__cpu_to_le32(MD_FEATURE_BITMAP_OFFSET);
+		if (bms->version == BITMAP_MAJOR_CLUSTERED)
+			sb->resync_offset = MaxSector;
 	} else if (strcmp(update, "bbl") == 0) {
 		/* only possible if there is room after the bitmap, or if
 		 * there is no bitmap
-- 
2.30.0


                 reply index

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=1612274021-21899-1-git-send-email-heming.zhao@suse.com \
    --to=heming.zhao@suse.com \
    --cc=jes@trained-monkey.org \
    --cc=lidong.zhong@suse.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=xni@redhat.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

Linux-Raid Archives on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-raid/0 linux-raid/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-raid linux-raid/ https://lore.kernel.org/linux-raid \
		linux-raid@vger.kernel.org
	public-inbox-index linux-raid

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-raid


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git