summaryrefslogtreecommitdiffstats
path: root/arch/ia64/Kconfig
diff options
context:
space:
mode:
authorNeil Brown <neilb@notabene.brown>2008-06-28 08:30:52 +1000
committerNeil Brown <neilb@notabene.brown>2008-06-28 08:30:52 +1000
commit8c2e870a625bd336b2e7a65a97c1836acef07322 (patch)
tree1d0650ce9affed0bfae754e17bd5a86a563f8037 /arch/ia64/Kconfig
parent543cf4cb3fe6f6cae3651ba918b9c56200b257d0 (diff)
downloadop-kernel-dev-8c2e870a625bd336b2e7a65a97c1836acef07322.zip
op-kernel-dev-8c2e870a625bd336b2e7a65a97c1836acef07322.tar.gz
Ensure interrupted recovery completed properly (v1 metadata plus bitmap)
If, while assembling an array, we find a device which is not fully in-sync with the array, it is important to set the "fullsync" flags. This is an exact analog to the setting of this flag in hot_add_disk methods. Currently, only v1.x metadata supports having devices in an array which are not fully in-sync (it keep track of how in sync they are). The 'fullsync' flag only makes a difference when a write-intent bitmap is being used. In this case it tells recovery to ignore the bitmap and recovery all blocks. This fix is already in place for raid1, but not raid5/6 or raid10. So without this fix, a raid1 ir raid4/5/6 array with version 1.x metadata and a write intent bitmaps, that is stopped in the middle of a recovery, will appear to complete the recovery instantly after it is reassembled, but the recovery will not be correct. If you might have an array like that, issueing echo repair > /sys/block/mdXX/md/sync_action will make sure recovery completes properly. Cc: <stable@kernel.org> Signed-off-by: Neil Brown <neilb@suse.de>
Diffstat (limited to 'arch/ia64/Kconfig')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud