All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ewan D. Milne" <emilne@redhat.com>
To: Hannes Reinecke <hare@suse.de>,
	"Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>,
	James Bottomley <james.bottomley@hansenpartnership.com>,
	Martin Wilck <martin.wilck@suse.com>,
	linux-scsi@vger.kernel.org, Hannes Reinecke <hare@suse.com>
Subject: Re: [PATCH] scsi_dh_alua: handle RTPG sense code correctly during state transitions
Date: Tue, 08 Oct 2019 11:58:53 -0400	[thread overview]
Message-ID: <279be0eb137c93f3d4010935cfa2922cabab8548.camel@redhat.com> (raw)
In-Reply-To: <220f6ffe-1657-f95f-c948-219b45f9496f@suse.de>

On Tue, 2019-10-08 at 08:21 +0200, Hannes Reinecke wrote:
> On 10/7/19 10:45 PM, Ewan D. Milne wrote:
> > 
> > The patch itself looks OK, but I was wondering about a couple of things:
> > 
> >   - There are other places in scsi_dh_alua where the ASC/ASCQ 04 0A is checked
> >     and we retry, I understand that this is a particular case you are solving
> >     but is the changing of the state to -> transitioning (because that's what
> >     the device said the state was) applicable in those other cases?
> 
> No. The original code was built around the assumption that RTPG would
> return the status of the device; consequently we would have to retry
> RTPG until we get a final status. But as mentioned, there are arrays
> which cannot return RTPG data during transitioning, so the code would
> never be able to detect a transitioning state.
> With this patch we set the state directly once the said sense code is
> received.
> But this applies _only_ to the RTPG command, as this is required to move
> the state machine along.
> None of the other commands are affected.
> 
> >   - The code originally seems to have been under the assumption that the
> >     transitioning state was a transient event, so the retry would pick up
> >     the eventual state.  Now, some storage arrays spend a long time in the
> >     transitioning state, but if we don't send another command are we going to
> >     get the sense (or the UA) that triggers entry to the eventual ALUA state?
> > 
> 
> Note, there are two types of retries.
> The one is the 'normal' command retry, where we resend a command a given
> number of times to retrieve the final status.
> This is precisely the error which caused this patch.
> 
> And then there is a scheduled retry; here we essentially poll the array
> with sending RTPG in regular intervals until the 'transitioning' state
> is gone. (Check for 'alua_rtpg()' and the handling of the SCSI_DH_RETRY
> return value). With the patch we continue to trigger that second type of
> retries, which will eventually clear the transitioning state.
> 
> Cheers,
> 
> Hannes

Thanks for the explanation.  The patch looks good.

Reviewed-by: Ewan D. Milne <emilne@redhat.com>


  reply	other threads:[~2019-10-08 15:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-07 13:57 [PATCH] scsi_dh_alua: handle RTPG sense code correctly during state transitions Hannes Reinecke
2019-10-07 14:15 ` Laurence Oberman
2019-10-07 20:45 ` Ewan D. Milne
2019-10-08  6:21   ` Hannes Reinecke
2019-10-08 15:58     ` Ewan D. Milne [this message]
2019-10-09 16:31 ` Bart Van Assche
2019-10-10  2:43 ` Martin K. Petersen

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=279be0eb137c93f3d4010935cfa2922cabab8548.camel@redhat.com \
    --to=emilne@redhat.com \
    --cc=hare@suse.com \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=james.bottomley@hansenpartnership.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=martin.wilck@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.