[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] [PATCH 1/9] blk: Do not abort requests if queue is stopped



On 05/04/2010 11:52 PM, Mike Anderson wrote:
Jens Axboe<jens axboe oracle com>  wrote:
On Mon, May 03 2010, Mike Anderson wrote:
If the queue is stopped it could be an indication that other recovery is
happening in this case skip the blk_abort_request.

Signed-off-by: Mike Anderson<andmike linux vnet ibm com>
Cc: Jens Axobe<jens axboe oracle com>
---
  block/blk-timeout.c |    3 ++-
  1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/block/blk-timeout.c b/block/blk-timeout.c
index 1ba7e0a..89fbe0a 100644
--- a/block/blk-timeout.c
+++ b/block/blk-timeout.c
@@ -224,7 +224,8 @@ void blk_abort_queue(struct request_queue *q)
  	list_splice_init(&q->timeout_list,&list);

  	list_for_each_entry_safe(rq, tmp,&list, timeout_list)
-		blk_abort_request(rq);
+		if (!blk_queue_stopped(q))
+			blk_abort_request(rq);

  	/*
  	 * Occasionally, blk_abort_request() will return without

That seems like a bit of a mixup, what ties a stopped queue to recovery?

This was coding to SCSI behavior again. I tried to reduce the case of
waking the eh if the transport moved the target into a blocked state. It
might be redundant as FC has eh blocking and timer_reset. iSCSI has
blocking but not eh blocking.

All iscsi drivers should have blocking and timer reset now, so if a transport problem casues a IO error to be sent to dm, then when blk_abort_request is called that should prevent the scsi layer from sending the whole host into recovery.


I do not remember the problem with the lack of eh blocking though. Did we need that too?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]