Re: [PATCH 3/7] fc class: Add support for new transport errors

[James Smart <James.Smart@emulex.com>]

Ack.

Although, I have the personal style preference of :
   rport->flags &= ~(FC_RPORT_FAST_FAIL_TIMEDOUT |
                     FC_RPORT_DEVLOSS_PENDING);
over
  >
  > +	rport->flags &= ~FC_RPORT_FAST_FAIL_TIMEDOUT;
  >  	rport->flags &= ~FC_RPORT_DEVLOSS_PENDING;
  >

-- james s

michaelc@cs.wisc.edu wrote:
> From: Mike Christie <michaelc@cs.wisc.edu>
> 
> When we block a rport and the driver implements the terminate
> callback we will fail IO that was running quickly. However
> IO that was in the scsi_device/block queue sits there until
> the dev_loss_tmo fires, and this can make it look like IO is
> lost because new IO will get executed but that IO stuck in
> the blocked queue sits there for some time longer.
> 
> With this patch when the fast io fail tmo fires, we will
> fail the blocked IO and any new IO. This patch also allows
> all drivers to partially support the fast io fail tmo. If the
> terminate io callback is not implemented, we will still fail blocked
> IO and any new IO, so multipath can handle that. This means that for
> drivers like qla2xxx which seem to fail the IO when the error is first
> detected this will then allow drivers like lpfc and qla2xxx to have the
> IO flushed to the upper layers when the fast io fail tmo is fired.
> 
> This patch also allows the fc and iscsi classes to implement the
> same behavior. The timers are just unfornately named differently.
> 
> The next patches will convert the drivers to support this.
> 
> This patch has been lightly tested with lpfc and qla2xxx. I am not able
> to test the role change handling.
> 
> Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
> ---
>  drivers/scsi/scsi_transport_fc.c |   15 ++++++++++-----
>  include/scsi/scsi_transport_fc.h |    8 ++++++--
>  2 files changed, 16 insertions(+), 7 deletions(-)