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 [thread overview]
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 other threads:[~2021-02-02 19:41 UTC|newest]
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
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;
as well as URLs for NNTP newsgroup(s).