summaryrefslogtreecommitdiffstats
path: root/include
diff options
context:
space:
mode:
authorNeilBrown <neilb@suse.de>2008-05-23 13:04:39 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2008-05-24 09:56:10 -0700
commitdfc7064500061677720fa26352963c772d3ebe6b (patch)
treea8ca495bccf98837c6762ffba54a8009c9772259 /include
parent90b08710e41a07d4ff0fb8940dcce3a552991a56 (diff)
downloadop-kernel-dev-dfc7064500061677720fa26352963c772d3ebe6b.zip
op-kernel-dev-dfc7064500061677720fa26352963c772d3ebe6b.tar.gz
md: restart recovery cleanly after device failure.
When we get any IO error during a recovery (rebuilding a spare), we abort the recovery and restart it. For RAID6 (and multi-drive RAID1) it may not be best to restart at the beginning: when multiple failures can be tolerated, the recovery may be able to continue and re-doing all that has already been done doesn't make sense. We already have the infrastructure to record where a recovery is up to and restart from there, but it is not being used properly. This is because: - We sometimes abort with MD_RECOVERY_ERR rather than just MD_RECOVERY_INTR, which causes the recovery not be be checkpointed. - We remove spares and then re-added them which loses important state information. The distinction between MD_RECOVERY_ERR and MD_RECOVERY_INTR really isn't needed. If there is an error, the relevant drive will be marked as Faulty, and that is enough to ensure correct handling of the error. So we first remove MD_RECOVERY_ERR, changing some of the uses of it to MD_RECOVERY_INTR. Then we cause the attempt to remove a non-faulty device from an array to fail (unless recovery is impossible as the array is too degraded). Then when remove_and_add_spares attempts to remove the devices on which recovery can continue, it will fail, they will remain in place, and recovery will continue on them as desired. Issue: If we are halfway through rebuilding a spare and another drive fails, and a new spare is immediately available, do we want to: 1/ complete the current rebuild, then go back and rebuild the new spare or 2/ restart the rebuild from the start and rebuild both devices in parallel. Both options can be argued for. The code currently takes option 2 as a/ this requires least code change b/ this results in a minimally-degraded array in minimal time. Cc: "Eivind Sarto" <ivan@kasenna.com> Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'include')
-rw-r--r--include/linux/raid/md_k.h4
1 files changed, 1 insertions, 3 deletions
diff --git a/include/linux/raid/md_k.h b/include/linux/raid/md_k.h
index a6d7ab6..3dea9f5 100644
--- a/include/linux/raid/md_k.h
+++ b/include/linux/raid/md_k.h
@@ -188,8 +188,7 @@ struct mddev_s
* NEEDED: we might need to start a resync/recover
* RUNNING: a thread is running, or about to be started
* SYNC: actually doing a resync, not a recovery
- * ERR: and IO error was detected - abort the resync/recovery
- * INTR: someone requested a (clean) early abort.
+ * INTR: resync needs to be aborted for some reason
* DONE: thread is done and is waiting to be reaped
* REQUEST: user-space has requested a sync (used with SYNC)
* CHECK: user-space request for for check-only, no repair
@@ -199,7 +198,6 @@ struct mddev_s
*/
#define MD_RECOVERY_RUNNING 0
#define MD_RECOVERY_SYNC 1
-#define MD_RECOVERY_ERR 2
#define MD_RECOVERY_INTR 3
#define MD_RECOVERY_DONE 4
#define MD_RECOVERY_NEEDED 5
OpenPOWER on IntegriCloud