Linux RAID subsystem development
 help / color / mirror / Atom feed
* [PATCH] raid5-cache: don't delay stripe captured in log
@ 2015-09-04 21:14 Shaohua Li
  0 siblings, 0 replies; only message in thread
From: Shaohua Li @ 2015-09-04 21:14 UTC (permalink / raw)
  To: linux-raid; +Cc: Kernel-team, songliubraving, hch, dan.j.williams, neilb

There is a case a stripe gets delayed forever.
1. a stripe finishes construction
2. a new bio hits the stripe
3. handle_stripe runs for the stripe. The stripe gets DELAYED bit set
since construction can't run for new bio (the stripe is locked since
step 1)

Without log, handle_stripe will call ops_run_io. After IO finishes, the
stripe gets unlocked and the stripe will restart and run construction
for the new bio. With log, ops_run_io need to run two times. If the
DELAYED bit set, the stripe can't enter into the handle_list, so the
second ops_run_io doesn't run, which leaves the stripe stalled.

Signed-off-by: Shaohua Li <shli@fb.com>
---
 drivers/md/raid5-cache.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
index 2dea05f..785749b1 100644
--- a/drivers/md/raid5-cache.c
+++ b/drivers/md/raid5-cache.c
@@ -474,6 +474,11 @@ int r5l_write_stripe(struct r5l_log *log, struct stripe_head *sh)
 		return -EINVAL;
 
 	set_bit(STRIPE_LOG_TRAPPED, &sh->state);
+	/*
+	 * The stripe must enter state machine again to finish the write, so
+	 * don't delay.
+	 * */
+	clear_bit(STRIPE_DELAYED, &sh->state);
 	atomic_inc(&sh->count);
 
 	mutex_lock(&log->io_mutex);
-- 
1.8.1


^ permalink raw reply related	[flat|nested] only message in thread

only message in thread, other threads:[~2015-09-04 21:14 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-09-04 21:14 [PATCH] raid5-cache: don't delay stripe captured in log Shaohua Li

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox