From: Sagi Grimberg <sagi@grimberg.me>
To: Christoph Hellwig <hch@infradead.org>
Cc: Keith Busch <kbusch@kernel.org>,
"Anner, Ran" <Ran.Anner@dell.com>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
"Engel, Amit" <Amit.Engel@dell.com>
Subject: Re: nvme reservation commands during controller reset
Date: Mon, 17 Aug 2020 00:56:47 -0700 [thread overview]
Message-ID: <e312ae98-5b40-d0ee-c13e-b65db1f3acd7@grimberg.me> (raw)
In-Reply-To: <20200815070134.GB20460@infradead.org>
>>> 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).
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).
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2020-08-17 7:56 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 [this message]
2020-08-17 8:12 ` Christoph Hellwig
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=e312ae98-5b40-d0ee-c13e-b65db1f3acd7@grimberg.me \
--to=sagi@grimberg.me \
--cc=Amit.Engel@dell.com \
--cc=Ran.Anner@dell.com \
--cc=hch@infradead.org \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
/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).