From: Hannes Reinecke <hare@suse.de>
To: Sagi Grimberg <sagi@grimberg.me>,
James Smart <james.smart@broadcom.com>,
Victor Gladkov <Victor.Gladkov@kioxia.com>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>
Cc: Keith Busch <kbusch@kernel.org>, Christoph Hellwig <hch@lst.de>,
"Ewan D. Milne" <emilne@redhat.com>
Subject: Re: [PATCH v7] nvme-fabrics: reject I/O to offline device
Date: Fri, 10 Jul 2020 08:58:46 +0200 [thread overview]
Message-ID: <6232a445-f898-5294-77a1-6a06ee94717d@suse.de> (raw)
In-Reply-To: <fee0ecca-3d31-a04f-af7c-7a3aada9d6fe@grimberg.me>
On 7/10/20 6:50 AM, Sagi Grimberg wrote:
>
>> Looks good to me. Only nit I see is - why are we checking ctrl->opts
>> in the xxx_failfast_work() routines ?
>
> Which brings me to the question, is there any desire to have this
> behavior in pci as well?
I was under the impression that an offline NVMe-PCI device is a pretty
terminal condition. This patch only would make sense if a reconnect
would be able to recover this situation.
For NVMe-PCI we would notify the application earlier; device's still
dead, though, so I'm not sure if that makes a huge difference.
Nor should it be a common occurence.
Unless you talk about ARM servers, for which frying NVMe devices seems
to be a hobby :-)
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2020-07-10 6:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-08 15:07 [PATCH v7] nvme-fabrics: reject I/O to offline device Victor Gladkov
2020-07-09 20:34 ` James Smart
2020-07-10 4:50 ` Sagi Grimberg
2020-07-10 6:58 ` Hannes Reinecke [this message]
2020-07-14 11:04 ` Christoph Hellwig
2020-07-22 22:57 ` Sagi Grimberg
2020-08-09 15:32 ` Victor Gladkov
2020-08-11 20:56 ` Sagi Grimberg
2020-08-12 14:09 ` Victor Gladkov
2020-08-13 15:00 ` James Smart
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=6232a445-f898-5294-77a1-6a06ee94717d@suse.de \
--to=hare@suse.de \
--cc=Victor.Gladkov@kioxia.com \
--cc=emilne@redhat.com \
--cc=hch@lst.de \
--cc=james.smart@broadcom.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 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.