From: Sagi Grimberg <sagi@grimberg.me>
To: Keith Busch <kbusch@kernel.org>, "Engel, Amit" <Amit.Engel@dell.com>
Cc: Christoph Hellwig <hch@infradead.org>,
"Anner, Ran" <Ran.Anner@dell.com>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>
Subject: Re: nvme reservation commands during controller reset
Date: Tue, 11 Aug 2020 13:48:20 -0700 [thread overview]
Message-ID: <462babf2-7cde-af4a-8bf9-a5b230e282b7@grimberg.me> (raw)
In-Reply-To: <20200810154846.GB4159317@dhcp-10-100-145-180.wdl.wdc.com>
>> We saw that in case of path error, nvme reservation cmds does not get error handling.
>> This is true via the blk layer as well as nvme-cli.
>>
>> We are working on implementing nvmeof stack and
>> this current behavior is blocking our host from running nvme reservation cmds during path error.
>
> What's blocking you from retrying this command in your host software?
>
> If we truly want to provide a way to hide intermittent errors on
> passthrough commands via automatic retry, it may be a little longer
> before such an interface hits a released kernel.
I think we need to keep the passthru commands as they are, but
reservations coming from the pr_ops maybe we can failover these
in nvme_pr_command?
What is the semantics in scsi btw? Didn't see any failover functionality
for pr_ops...
_______________________________________________
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-11 20:48 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 [this message]
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
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=462babf2-7cde-af4a-8bf9-a5b230e282b7@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 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.