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

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

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.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@suse.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer