aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/md/raid10.c
diff options
context:
space:
mode:
authorNeilBrown <neilb@suse.de>2010-12-09 16:36:28 +1100
committerNeilBrown <neilb@suse.de>2010-12-09 16:36:28 +1100
commit1a855a0606653d2d82506281e2c686bacb4b2f45 (patch)
tree7eeca410e738491318c0d80bd0a0940c392e513f /drivers/md/raid10.c
parenta035fc3e2531703b539f23bec4ca7943cfc69349 (diff)
downloadkernel_samsung_tuna-1a855a0606653d2d82506281e2c686bacb4b2f45.zip
kernel_samsung_tuna-1a855a0606653d2d82506281e2c686bacb4b2f45.tar.gz
kernel_samsung_tuna-1a855a0606653d2d82506281e2c686bacb4b2f45.tar.bz2
md: fix bug with re-adding of partially recovered device.
With v0.90 metadata, a hot-spare does not become a full member of the array until recovery is complete. So if we re-add such a device to the array, we know that all of it is as up-to-date as the event count would suggest, and so it a bitmap-based recovery is possible. However with v1.x metadata, the hot-spare immediately becomes a full member of the array, but it record how much of the device has been recovered. If the array is stopped and re-assembled recovery starts from this point. When such a device is hot-added to an array we currently lose the 'how much is recovered' information and incorrectly included it as a full in-sync member (after bitmap-based fixup). This is wrong and unsafe and could corrupt data. So be more careful about setting saved_raid_disk - which is what guides the re-adding of devices back into an array. The new code matches the code in slot_store which does a similar thing, which is encouraging. This is suitable for any -stable kernel. Reported-by: "Dailey, Nate" <Nate.Dailey@stratus.com> Cc: stable@kernel.org Signed-off-by: NeilBrown <neilb@suse.de>
Diffstat (limited to 'drivers/md/raid10.c')
0 files changed, 0 insertions, 0 deletions