Re: [PATCH v2 3/3] md/raid10: skip clean regions in bulk during recovery

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