aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/md/md.h
diff options
context:
space:
mode:
authorNeilBrown <neilb@suse.de>2009-03-30 23:33:13 -0400
committerNeilBrown <neilb@suse.de>2009-03-30 23:33:13 -0400
commit97e4f42d62badb0f9fbc27c013e89bc1336a03bc (patch)
tree04cc809702a6b080c417c4ddf605642bbf7de521 /drivers/md/md.h
parent43b2e5d86d8bdd77386226db0bc961529492c043 (diff)
md: occasionally checkpoint drive recovery to reduce duplicate effort after a crash
Version 1.x metadata has the ability to record the status of a partially completed drive recovery. However we only update that record on a clean shutdown. It would be nice to update it on unclean shutdowns too, particularly when using a bitmap that removes much to the 'sync' effort after an unclean shutdown. One complication with checkpointing recovery is that we only know where we are up to in terms of IO requests started, not which ones have completed. And we need to know what has completed to record how much is recovered. So occasionally pause the recovery until all submitted requests are completed, then update the record of where we are up to. When we have a bitmap, we already do that pause occasionally to keep the bitmap up-to-date. So enhance that code to record the recovery offset and schedule a superblock update. And when there is no bitmap, just pause 16 times during the resync to do a checkpoint. '16' is a fairly arbitrary number. But we don't really have any good way to judge how often is acceptable, and it seems like a reasonable number for now. Signed-off-by: NeilBrown <neilb@suse.de>
Diffstat (limited to 'drivers/md/md.h')
-rw-r--r--drivers/md/md.h7
1 files changed, 7 insertions, 0 deletions
diff --git a/drivers/md/md.h b/drivers/md/md.h
index e78b3c1d55fd..bede26c9d4a9 100644
--- a/drivers/md/md.h
+++ b/drivers/md/md.h
@@ -159,6 +159,13 @@ struct mddev_s
159 struct mdk_thread_s *thread; /* management thread */ 159 struct mdk_thread_s *thread; /* management thread */
160 struct mdk_thread_s *sync_thread; /* doing resync or reconstruct */ 160 struct mdk_thread_s *sync_thread; /* doing resync or reconstruct */
161 sector_t curr_resync; /* last block scheduled */ 161 sector_t curr_resync; /* last block scheduled */
162 /* As resync requests can complete out of order, we cannot easily track
163 * how much resync has been completed. So we occasionally pause until
164 * everything completes, then set curr_resync_completed to curr_resync.
165 * As such it may be well behind the real resync mark, but it is a value
166 * we are certain of.
167 */
168 sector_t curr_resync_completed;
162 unsigned long resync_mark; /* a recent timestamp */ 169 unsigned long resync_mark; /* a recent timestamp */
163 sector_t resync_mark_cnt;/* blocks written at resync_mark */ 170 sector_t resync_mark_cnt;/* blocks written at resync_mark */
164 sector_t curr_mark_cnt; /* blocks scheduled now */ 171 sector_t curr_mark_cnt; /* blocks scheduled now */