On 05/04/2010 11:52 PM, Mike Anderson wrote:
Jens Axboe<jens.axboe@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx>
Cc: Jens Axobe<jens.axboe@xxxxxxxxxx>
---
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?
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
