On Apr 17, 2012, at 10:48 PM, NeilBrown wrote:

On Tue, 17 Apr 2012 21:30:19 -0500 Jonathan Brassow [off-list ref]
wrote:

quoted

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