[dm-devel] [PATCH 0 of 4] dm-raid: various bug fixes
Brassow Jonathan
jbrassow at redhat.com
Wed Apr 18 14:05:59 UTC 2012
On Apr 17, 2012, at 10:48 PM, NeilBrown wrote:
> On Tue, 17 Apr 2012 21:30:19 -0500 Jonathan Brassow <jbrassow at redhat.com>
> wrote:
>
>> Neil,
>>
>> I've cleaned up the first two patches I sent earlier:
>> [1 of 5] dm-raid-set-recovery-flags-on-resume.patch
>> [2 of 5] dm-raid-record-and-handle-missing-devices.patch
>> and added a couple more:
>> [3 of 5] dm-raid-need-safe-version-of-rdev_for_each.patch
>> [4 of 5] dm-raid-use-md_error-in-place-of-faulty-bit.patch
>> [5 of 5] md-raid1-further-conditionalize-fullsync.patch
>>
>> Patch [5 of 5] I think needs some work. It fixes the problem I'm seeing
>> and seems to go along with similar logic used for RAID5 in commit
>> d6b212f4b19da5301e6b6eca562e5c7a2a6e8c8d. It also seems like a workable
>> solution based on the code surrounding commit
>> d30519fc59c5cc2f7772fa67b16b1a2426d36c95. Can you let me know if I'm
>> stretching the usage of 'saved_raid_disk' too far?
>>
>> Thanks,
>> brassow
>
> Thanks.
>
> 3-of-5 should go in 3.4 presumably. The rest wait for 3.5? Or do you think
> they should be in 3.4?
>
> 5-of-5: Maybe it would make sense just to check if saved_raid_disk >= 0 ??
>
> This is only relevant for dm-raid isn't it? I'd need to think through how
> all that fits together again.
>
> The rest are all fine and are in my for-next
Thanks Neil,
Yes, 3-of-5 should probably go in sooner rather than later. Waiting on the others shouldn't hurt.
5-of-5: changing the check to 'saved_raid_disk >= 0' would be fine, but I think I should initialize 'saved_raid_disk' to -1 in dm-raid.c then normally. Right now, an nominal initial value is not set - meaning it is '0'. (When a device comes back from a failure, 'saved_raid_disk' is assigned its old position.)
brassow
More information about the dm-devel
mailing list