From: "yu kuai" <yukuai@fygo.io>
To: "Yunye Zhao" <yunye.zhao@linux.alibaba.com>, "yu kuai" <yukuai@fygo.io>
Cc: <joseph.qi@linux.alibaba.com>, <linux-kernel@vger.kernel.org>,
<linux-raid@vger.kernel.org>, <magiclinan@didiglobal.com>,
<sashiko-bot@kernel.org>, <song@kernel.org>, <xiao@kernel.org>
Subject: Re: [PATCH v2 3/3] md/raid10: skip clean regions in bulk during recovery
Date: Tue, 4 Aug 2026 19:47:50 +0800 [thread overview]
Message-ID: <e22f9816-fb97-49aa-a4d2-b098ccafb654@fygo.io> (raw)
In-Reply-To: <20260804090110.111062-1-yunye.zhao@linux.alibaba.com>
Hi,
在 2026/8/4 17:01, Yunye Zhao 写道:
> Hi Kuai,
>
>> By re-add a disk, this is really a resync, and bitmap can be used in
>> this case to skip clean bits. In this case, I still think the correct
>> solution, for old bitmap, is to let bitmap_start_sync() return much
>> bigger skipped blocks.
> Thanks for the correction. Just to describe how md currently drives it:
> with no resync pending, md_choose_sync_action() takes the re-added member
> as a spare from remove_and_add_spares(), then clears MD_RECOVERY_SYNC and
> sets MD_RECOVERY_RECOVER (md.c:10151-10163). md_sync_position() then
> starts the sweep at rdev->recovery_offset (md.c:9557) and
> md_sync_max_sectors() bounds it by mddev->dev_sectors (md.c:9489). So a
> re-add runs raid10_sync_request()'s recovery branch, in device address
> space, rather than the resync branch.
Yes
>
> md_run() defaults the bitmap/resync space to the device space, and raid10
> is the only personality that overrides it:
>
> md_run() resync_max_sectors = mddev->dev_sectors md.c:6753
> raid5 resync_max_sectors = mddev->dev_sectors raid5.c:8090
> raid10 resync_max_sectors = raid10_size(mddev, 0, 0) raid10.c:4149
>
> So in the recovery branch sync_blocks is in array sectors while the return
> value advances a device cursor - for a near layout the two differ by
> raid_disks / near_copies (raid10_find_virt(), raid10.c:699).
I still don't understand why this will avoid you been using skip_sectors returned
from bitmap_start_sync():
For example, a 4 1T disks raid10 with near=2, assume re-add a rdev with bitmap all
clean, you first pass in sect=0 to bitmap_start_sync(), then skip_sectors, ideally,
can be set to full array size 2T, then you can map the array 2T back to rdev, which
you'll get 1T. Do this in the loop and choose the minimal for all members, finally
you can skip 1T at a time.
Check the code, currently raid10 do not map the max_sync, which is RESYNC_PAGES, back
to rdev sector, and use it directly. I wonder is this safe for raid10 with chunksize less
than RESYNC_PAGES?
>
> If I read you right, you would prefer this fixed on the bitmap side rather
> than in raid10.c. For the recovery branch to use the reported span
> directly, that span has to be in the device address space, so md-bitmap.c
> would need the raid10 geometry. I will look into how that can be
> implemented.
I still don't get why
>
> Thanks,
> Yunye
--
Thanks,
Kuai
next prev parent reply other threads:[~2026-08-04 11:48 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-17 6:27 [PATCH] md: fix soft lockup during resync when sync is repeatedly skipped Yunye Zhao
2026-07-19 10:45 ` yu kuai
2026-07-20 6:20 ` Yunye Zhao
2026-07-22 4:00 ` yu kuai
2026-07-23 13:55 ` [PATCH v2 0/3] md/raid10: fix recovery corruption and soft lockup on large arrays Yunye Zhao
2026-07-23 13:55 ` [PATCH v2 1/3] md/raid10: fix still_degraded being inverted in raid10_sync_request() Yunye Zhao
2026-07-26 12:25 ` Mykola Marzhan
2026-07-27 2:43 ` Yunye Zhao
2026-08-07 8:11 ` yu kuai
2026-07-23 13:55 ` [PATCH v2 2/3] md: add cond_resched() to md_do_sync()'s skip path Yunye Zhao
2026-08-07 8:11 ` yu kuai
2026-07-23 13:55 ` [PATCH v2 3/3] md/raid10: skip clean regions in bulk during recovery Yunye Zhao
2026-07-31 9:46 ` yu kuai
2026-08-04 3:55 ` Yunye Zhao
2026-08-04 6:57 ` yu kuai
2026-08-04 9:01 ` Yunye Zhao
2026-08-04 11:47 ` yu kuai [this message]
2026-08-07 9:05 ` Yunye Zhao
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=e22f9816-fb97-49aa-a4d2-b098ccafb654@fygo.io \
--to=yukuai@fygo.io \
--cc=joseph.qi@linux.alibaba.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=magiclinan@didiglobal.com \
--cc=sashiko-bot@kernel.org \
--cc=song@kernel.org \
--cc=xiao@kernel.org \
--cc=yunye.zhao@linux.alibaba.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
all inboxes | Powered by JetHome®