Re: [PATCH] scsi: do not retry FAILFAST commands on DID_TRANSPORT_DISRUPTED

On Thu, 2021-01-28 at 07:57 +0100, Hannes Reinecke wrote:

On 1/28/21 1:51 AM, michael.christie@oracle.com wrote:

quoted

On 1/26/21 7:02 AM, Hannes Reinecke wrote:

quoted

When a command is return with DID_TRANSPORT_DISRUPTED we should
be looking at the REQ_FAILFAST_TRANSPORT flag and do not retry
the command if set.
Otherwise multipath will be requeuing a command on the failed
path and not fail it over to one of the working paths.

Cc: Martin Wilck <redacted>
Signed-off-by: Hannes Reinecke <hare@suse.com>
---
  drivers/scsi/scsi_error.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/scsi_error.c

b/drivers/scsi/scsi_error.c
index a52665eaf288..005118385b70 100644

--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c

@@ -1753,6 +1753,7 @@ int scsi_noretry_cmd(struct scsi_cmnd

*scmd)
      case DID_TIME_OUT:
          goto check_type;
      case DID_BUS_BUSY:
+    case DID_TRANSPORT_DISRUPTED:
          return (scmd->request->cmd_flags &
REQ_FAILFAST_TRANSPORT);
      case DID_PARITY:
          return (scmd->request->cmd_flags & REQ_FAILFAST_DEV);

We don't fast fail for that error code to avoid churn for
transient 
transport problems. The FC and iscsi drivers block the
rport/session, 
return that code and then it's up the fast_io_fail/replacement
timeout.

_But_ if prevents that command to be failed over to another path, so 
essentially we're blocking execution until fast_io_fail tmo.

For no good reason as we have other paths available.

And if we don't?  Not everybody sets queue_if_no_path, right?

-Ewan
 

Cheers,

Hannes