From: Hannes Reinecke <hare@suse.de>
To: Sagi Grimberg <sagi@grimberg.me>,
Johannes Thumshirn <jthumshirn@suse.de>,
Christoph Hellwig <hch@lst.de>
Cc: Keith Busch <keith.busch@intel.com>,
Linux NVMe Mailinglist <linux-nvme@lists.infradead.org>,
Linux Kernel Mailinglist <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] nvme: make controller 'state' sysfs attribute pollable
Date: Mon, 25 Sep 2017 10:23:16 +0200 [thread overview]
Message-ID: <daf5fe87-6b93-68aa-65be-b442615b9bd0@suse.de> (raw)
In-Reply-To: <6d9304e2-f943-f063-1298-c6a2d582f78f@grimberg.me>
On 09/25/2017 09:09 AM, Sagi Grimberg wrote:
>
>
> On 25/09/17 08:59, Hannes Reinecke wrote:
>> On 09/25/2017 07:37 AM, Sagi Grimberg wrote:
>>>
>>>> So why exposing it then in the first time? I know you don't want
>>>> dm-mpath in
>>>> NVMe (neither do I) but we have to have something until your patchset
>>>> and ANA
>>>> is merged. And with this patch it's trivial to build a path checker
>>>> that just
>>>> looks at the state attribute in sysfs.
>>>
>>> Can't we just not use path-checkers for nvme (we already have one in
>>> nvme)?
>>
>> Really? For NVMe?
>> How would you do that, then?
>
> Quick and dirty is to have a path-checker that returns path-up always,
> when the path go down, nvme will detect it and fast-fail the io.
>
Well, yes; that's the trivial part.
But how do you know the path has become LIVE again?
>> Anyway: the entire point is that you don't _need_ a path checker for
>> NVMe.
>> The primary reason for path checkers is to check with the transport
>> layer if the remote endpoint is reachable.
>> (I know, that's not quite what they're doing now, but that's beside the
>> point).
>> For NVMf we do have KATO, so the NVMe subsystem knows exactly if the
>> connection is live or not. So it should be perfectly sufficient to check
>> the connection state instead of running a path checker of sorts.
>> But for doing so we need something in sysfs which we could check.
>>
>> Mind you, I wouldn't be adverse to have some common sysfs attribute,
>> with some common values (eg path up, path down, path blocked), and have
>> NVMf translating the internal state into that.
>
> We could have such an interface I assume. But it would suck to maintain
> yet another state (we are already having enough trouble to have a
> coherent controller state machine).
Weell ... we could be using a notifier chain for that.
I think I should post my patchset.
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
next prev parent reply other threads:[~2017-09-25 8:23 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-20 10:40 Johannes Thumshirn
2017-09-20 10:49 ` Sagi Grimberg
2017-09-20 14:59 ` Christoph Hellwig
2017-09-21 5:19 ` Johannes Thumshirn
2017-09-21 14:10 ` Christoph Hellwig
2017-09-25 5:37 ` Sagi Grimberg
2017-09-25 5:59 ` Hannes Reinecke
2017-09-25 7:09 ` Sagi Grimberg
2017-09-25 8:23 ` Hannes Reinecke [this message]
2017-09-25 12:52 ` Christoph Hellwig
2017-09-21 12:47 ` Guan Junxiong
2017-09-25 5:36 ` 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=daf5fe87-6b93-68aa-65be-b442615b9bd0@suse.de \
--to=hare@suse.de \
--cc=hch@lst.de \
--cc=jthumshirn@suse.de \
--cc=keith.busch@intel.com \
--cc=linux-kernel@vger.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
all inboxes | Powered by JetHome®