On Wed, Dec 06, 2017 at 08:11:30AM +0800, Qu Wenruo wrote: > > > On 2017年12月06日 06:55, Liu Bo wrote: > > On Tue, Dec 05, 2017 at 07:09:25PM +0100, David Sterba wrote: > >> On Tue, Dec 05, 2017 at 04:07:35PM +0800, Qu Wenruo wrote: > >>>> @@ -2166,11 +2166,21 @@ int raid56_parity_recover(struct btrfs_fs_info > >>>> *fs_info, struct bio *bio, > >>>> } > >>>> > >>>> /* > >>>> - * reconstruct from the q stripe if they are > >>>> - * asking for mirror 3 > >>>> + * Loop retry: > >>>> + * for 'mirror == 2', reconstruct from all other stripes. > >>> > >>> What about using macro to makes the reassemble method more human readable? > >> > >> Yeah, that's definetelly needed and should be based on > >> BTRFS_MAX_MIRRORS, not just hardcoded to 3. > > > > OK. > > > > In case of raid5/6, BTRFS_MAX_MIRRORS is an abused name, it's more a > > raid1/10 concept, either BTRFS_RAID56_FULL_REBUILD or > > BTRFS_RAID56_FULL_CHK is better to me, which one do you guys like? > > For mirror > 2 case, the mirror_num is no longer a single indicator, but > a ranged iterator for later rebuild retries. > > Something like set_raid_fail_from_mirror_num() seems better to me.
I feel like having the logic open-code'd plus necessary comments is probably better as we can see which stripe failb is. For those who are new to this raid6 retry logic are likely to feel confused by a helper function like set_raid_fail_from_mirror_num() and will go check the helper function about the retry logic. Thanks, -liubo -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
