md: Don't update ->recovery_offset when reshaping an array to fewer devices.
authorNeilBrown <neilb@suse.de>
Wed, 16 Jun 2010 07:01:25 +0000 (17:01 +1000)
committerNeilBrown <neilb@suse.de>
Thu, 24 Jun 2010 03:35:18 +0000 (13:35 +1000)
commit70fffd0bfab1558a8c64c5e903dea1fb84cd9f6b
tree126f2ae8faa2cff8f9dde91cc7a07569ff9851cb
parente4e11e385d1e5516ac76c956d6c25e6c2fa1b8d0
md: Don't update ->recovery_offset when reshaping an array to fewer devices.

When an array is reshaped to have fewer devices, the reshape proceeds
from the end of the devices to the beginning.

If a device happens to be non-In_sync (which is possible but rare)
we would normally update the ->recovery_offset as the reshape
progresses. However that would be wrong as the recover_offset records
that the early part of the device is in_sync, while in fact it would
only be the later part that is in_sync, and in any case the offset
number would be measured from the wrong end of the device.

Relatedly, if after a reshape a spare is discovered to not be
recoverred all the way to the end, not allow spare_active
to incorporate it in the array.

This becomes relevant in the following sample scenario:

A 4 drive RAID5 is converted to a 6 drive RAID6 in a combined
operation.
The RAID5->RAID6 conversion will cause a 5 drive to be included as a
spare, then the 5drive -> 6drive reshape will effectively rebuild that
spare as it progresses.  The 6th drive is treated as in_sync the whole
time as there is never any case that we might consider reading from
it, but must not because there is no valid data.

If we interrupt this reshape part-way through and reverse it to return
to a 5-drive RAID6 (or event a 4-drive RAID5), we don't want to update
the recovery_offset - as that would be wrong - and we don't want to
include that spare as active in the 5-drive RAID6 when the reversed
reshape completed and it will be mostly out-of-sync still.

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