Re: [PATCH] Do not requeue requests if FAILFAST is set

[Mike Christie <michaelc@cs.wisc.edu>]

Hannes Reinecke wrote:
> Hi James,
> 
> the FAILFAST flag is currently not honored in scsi_request_fn().
> So if scsi_dispatch_cmd() returns an error or the queue is not
> ready, the request will always be requeued regardless of the
> FAILFAST setting.
> This can result in a delayed fallback for multipathing, as
> these requests will only be catched once the timeout expires.
> 
> This patch avoids requeuing if the FAILFAST flag is set, and
> terminates the request immediately.
> 
> Comments et al welcome.
> 

I think that might be better than my transport errors patch. If 
multipath is being used then we told people to set the recovery timeout, 
to a very low value. So that way commands would not sit in a blocked 
queue very long.

With your patch, if the queue was blocked because we are doing recovery, 
then the command is returned upwards as soon as the driver/class returns 
the command to the scsi layer. And that is nice since it fixes that 
issue where the fibre channel class/driver fails commands in the driver 
when fail fast tmo fires, but commands in the blocked queue sit around 
until dev loss tmo fires or the rport comes back.

Is there any case though where fail fast is set on the request, but the 
driver really does want to retry on the driver? Was there some other 
user of something like DID_IMM_RETRY that could be used with multipath 
or raid and when they return DID_IMM_RETRY they wanted to bypass the 
fail fast checks? If so that would be my only reason for splitting up 
the error values and relying on the transport class timers (fc fail fast 
tmo and iscsi recovery tmo) to decide when to fail commands (assuming 
that the fc class is also changed so when fail fast tmo fires blocked 
commands are failed).

Oh yeah since we are now doing dm-multipath with SAS, what is that class 
doing as far as failing commands when there is a transport issue? Does 
it have something like fc's fail fast tmo? Does it fail running commands 
right away so the scsi layer can requeue or does it try to do some lower 
level recovery and try to continue the command until some timeout fires?