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

[Mike Christie]

On 05/04/2010 11:52 PM, Mike Anderson wrote:
> Jens Axboe<jens.axboe at 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 at linux.vnet.ibm.com>
>>> Cc: Jens Axobe<jens.axboe at 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?