linux-nvme.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Sagi Grimberg <sagi@grimberg.me>
Cc: Christoph Hellwig <hch@infradead.org>,
	Keith Busch <kbusch@kernel.org>,
	"Engel, Amit" <Amit.Engel@dell.com>,
	"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
	"Anner, Ran" <Ran.Anner@dell.com>
Subject: Re: nvme reservation commands during controller reset
Date: Mon, 17 Aug 2020 09:12:27 +0100	[thread overview]
Message-ID: <20200817081227.GA12680@infradead.org> (raw)
In-Reply-To: <e312ae98-5b40-d0ee-c13e-b65db1f3acd7@grimberg.me>

On Mon, Aug 17, 2020 at 12:56:47AM -0700, Sagi Grimberg wrote:
> 
> > > > Amit,
> > > > 
> > > > can you try the branch below?  Pretty much hot off the press, but I
> > > > think this should address your problem:
> > > > 
> > > > http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/nvme-pr-fix
> > > 
> > > I like the approach, but I think we'll need a bit more path awareness
> > > like we check for available paths if we requeue or fail..
> > 
> > If there is no available path, nvme_find_path will fail and thus we'll
> > error it.  This is the same mechanism as used by
> > nvme_ns_head_submit_bio.
> 
> nvme_find_path will return ns=NULL even if none of the paths is LIVE,
> but we want to requeue if we have an available path (e.g. ANA state is
> inaccessible temporarily or ctrl state is RESETTING/CONNECTING).

nvme_find_path will return a namespace if there is a namespace with
an optimized or non-optimized state, and which does not have the
NVME_NS_ANA_PENDING or NVME_NS_REMOVING flags set on a controller that is
in the live or deleting states.

And that is exactly what nvme_ns_head_submit_bio relies on.

> Only if no path is available for request execution we are failing the
> request.
> 
> If we are providing multipathing for reservations, we should give
> the same efforts as we do for normal I/O. This could mean waiting
> for some indication on the ns path states (wait for a completion in
> nvme_submit_sync_cmd_disk and wake it up in nvme_mpath_set_live).

The only difference in nvme_ns_head_submit_bio is that the bio is
queued up if the controller is in a suitable state.  But that isn't
something we can implement for the passthrough path as we don't have
an inidividual bio that we can queue up.  Note that not other retries
are handled by the pr path either, so there is the need for some
amount of retrying in the caller anyway.

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme

  reply	other threads:[~2020-08-17  8:15 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-05  7:14 nvme reservation commands during controller reset Engel, Amit
2020-08-09 16:10 ` Keith Busch
2020-08-10 12:40   ` Christoph Hellwig
2020-08-10 15:13     ` Engel, Amit
2020-08-10 15:48       ` Keith Busch
2020-08-11 20:48         ` Sagi Grimberg
2020-08-12  7:00           ` Engel, Amit
2020-08-14  8:20           ` Christoph Hellwig
2020-08-14 10:09             ` Christoph Hellwig
2020-08-14 16:02               ` Keith Busch
2020-08-15  7:00                 ` Christoph Hellwig
2020-08-14 18:29               ` Sagi Grimberg
2020-08-15  7:01                 ` Christoph Hellwig
2020-08-17  7:56                   ` Sagi Grimberg
2020-08-17  8:12                     ` Christoph Hellwig [this message]
2020-08-17 19:29                       ` Sagi Grimberg
2020-08-18  6:36                         ` Christoph Hellwig
2020-08-18 17:18                           ` Sagi Grimberg

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=20200817081227.GA12680@infradead.org \
    --to=hch@infradead.org \
    --cc=Amit.Engel@dell.com \
    --cc=Ran.Anner@dell.com \
    --cc=kbusch@kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=sagi@grimberg.me \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).