Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1738777
| From | Sagi Grimberg <sagi@grimberg.me> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] nvme: make controller 'state' sysfs attribute pollable |
| Date | 2017-09-25 09:10 +0200 |
| Message-ID | <utvGG-33T-13@gated-at.bofh.it> (permalink) |
| References | <urKJP-1Qq-3@gated-at.bofh.it> <urODM-4pI-21@gated-at.bofh.it> <us241-4Ve-3@gated-at.bofh.it> <utuhz-1YP-1@gated-at.bofh.it> <utuAV-287-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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. > 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).
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH] nvme: make controller 'state' sysfs attribute pollable Johannes Thumshirn <jthumshirn@suse.de> - 2017-09-20 12:50 +0200
Re: [PATCH] nvme: make controller 'state' sysfs attribute pollable Sagi Grimberg <sagi@grimberg.me> - 2017-09-20 12:50 +0200
Re: [PATCH] nvme: make controller 'state' sysfs attribute pollable Christoph Hellwig <hch@lst.de> - 2017-09-20 17:00 +0200
Re: [PATCH] nvme: make controller 'state' sysfs attribute pollable Johannes Thumshirn <jthumshirn@suse.de> - 2017-09-21 07:20 +0200
Re: [PATCH] nvme: make controller 'state' sysfs attribute pollable Christoph Hellwig <hch@lst.de> - 2017-09-21 16:20 +0200
Re: [PATCH] nvme: make controller 'state' sysfs attribute pollable Sagi Grimberg <sagi@grimberg.me> - 2017-09-25 07:40 +0200
Re: [PATCH] nvme: make controller 'state' sysfs attribute pollable Hannes Reinecke <hare@suse.de> - 2017-09-25 08:00 +0200
Re: [PATCH] nvme: make controller 'state' sysfs attribute pollable Sagi Grimberg <sagi@grimberg.me> - 2017-09-25 09:10 +0200
Re: [PATCH] nvme: make controller 'state' sysfs attribute pollable Hannes Reinecke <hare@suse.de> - 2017-09-25 10:30 +0200
Re: [PATCH] nvme: make controller 'state' sysfs attribute pollable Christoph Hellwig <hch@lst.de> - 2017-09-25 15:00 +0200
Re: [PATCH] nvme: make controller 'state' sysfs attribute pollable Guan Junxiong <guanjunxiong@huawei.com> - 2017-09-21 14:50 +0200
Re: [PATCH] nvme: make controller 'state' sysfs attribute pollable Sagi Grimberg <sagi@grimberg.me> - 2017-09-25 07:40 +0200
csiph-web