Don't unconditionally set in_sync on newly added device in raid5_reshape
authorNeilBrown <neilb@suse.de>
Fri, 13 Nov 2009 06:40:51 +0000 (17:40 +1100)
committerNeilBrown <neilb@suse.de>
Fri, 13 Nov 2009 06:40:51 +0000 (17:40 +1100)
When a reshape finds that it can add spare devices into the array,
those devices might already be 'in_sync' if they are beyond the old
size of the array, or they might not if they are within the array.

The first case happens when we change an N-drive RAID5 to an
N+1-drive RAID5.
The second happens when we convert an N-drive RAID5 to an
N+1-drive RAID6.

So set the flag more carefully.
Also, ->recovery_offset is only meaningful when the flag is clear,
so only set it in that case.

This change needs the preceding two to ensure that the non-in_sync
device doesn't get evicted from the array when it is stopped, in the
case where v0.90 metadata is used.

Signed-off-by: NeilBrown <neilb@suse.de>
drivers/md/raid5.c

index dcce204..ab40529 100644 (file)
@@ -5361,9 +5361,11 @@ static int raid5_start_reshape(mddev_t *mddev)
                    !test_bit(Faulty, &rdev->flags)) {
                        if (raid5_add_disk(mddev, rdev) == 0) {
                                char nm[20];
-                               set_bit(In_sync, &rdev->flags);
+                               if (rdev->raid_disk >= conf->previous_raid_disks)
+                                       set_bit(In_sync, &rdev->flags);
+                               else
+                                       rdev->recovery_offset = 0;
                                added_devices++;
-                               rdev->recovery_offset = 0;
                                sprintf(nm, "rd%d", rdev->raid_disk);
                                if (sysfs_create_link(&mddev->kobj,
                                                      &rdev->kobj, nm))