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

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.

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).

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.

Thanks,
Yunye