All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Mike Christie <michael.christie@oracle.com>
Cc: mwilck@suse.com,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Christoph Hellwig <hch@lst.de>,
	linux-scsi@vger.kernel.org, Hannes Reinecke <hare@suse.de>,
	Ming Lei <ming.lei@redhat.com>,
	Bart Van Assche <Bart.VanAssche@sandisk.com>,
	Dave Prizer <dave.prizer@hpe.com>
Subject: Re: [PATCH RESEND] scsi: scan: retry INQUIRY after timeout
Date: Tue, 9 Aug 2022 08:52:47 +0200	[thread overview]
Message-ID: <20220809065247.GA9663@lst.de> (raw)
In-Reply-To: <251c6042-5778-5d82-64e3-a2de5e1e2d36@oracle.com>

On Mon, Aug 08, 2022 at 05:11:27PM -0500, Mike Christie wrote:
> For REPORT_LUNS it looks like we retry almost all errors 3 times. For the
> probe/setup commands, at least for disks, it looks like we also are more
> forgiving and will retry DID_TIME_OUT/DID_TRANSPORT_DISRUPTED 3 times for
> commands like SAI_READ_CAPACITY_16 (I didn't check every sd operation and
> other upper level drivers).
> 
> However, for the other probe/setup  operations that rely on scsi_attach_vpd
> succeeding like sd_read_block_limits then we will hit issues where the device
> is partially setup. Should scsi_vpd_inquiry be retrying 3 times as well?
> 
> An alternative to changing all the callers would be we could make scsi_noretry_cmd
> detect when it's an internal passthrough command and just retry these types of
> errors. For SG IO type of passthough we still want to fail right away.

Yes, I think one single place to do retries for setup path command
is much better than growing ad-hoc logic.

I just made a similar comment to similar nvme patch from SuSE a few days
ago..

  reply	other threads:[~2022-08-09  6:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-08 20:20 [PATCH RESEND] scsi: scan: retry INQUIRY after timeout mwilck
2022-08-08 22:11 ` Mike Christie
2022-08-09  6:52   ` Christoph Hellwig [this message]
2022-08-09  8:50     ` Martin Wilck
2022-08-09  8:51       ` Christoph Hellwig
2022-08-09  8:21   ` Martin Wilck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220809065247.GA9663@lst.de \
    --to=hch@lst.de \
    --cc=Bart.VanAssche@sandisk.com \
    --cc=dave.prizer@hpe.com \
    --cc=hare@suse.de \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=michael.christie@oracle.com \
    --cc=ming.lei@redhat.com \
    --cc=mwilck@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.