From: Guixin Liu <kanie@linux.alibaba.com>
To: Nilay Shroff <nilay@linux.ibm.com>,
Keith Busch <kbusch@kernel.org>, Jens Axboe <axboe@kernel.dk>,
Christoph Hellwig <hch@lst.de>, Sagi Grimberg <sagi@grimberg.me>,
Daniel Wagner <dwagner@suse.de>
Cc: linux-nvme@lists.infradead.org
Subject: Re: [PATCH v2] nvme-multipath: expose path_state via sysfs
Date: Tue, 23 Jun 2026 15:54:21 +0800 [thread overview]
Message-ID: <d34f4f41-fc35-4df9-b657-e84b520a6784@linux.alibaba.com> (raw)
In-Reply-To: <47b1fee5-c7e8-4fd5-884f-80e651181407@linux.ibm.com>
在 2026/6/23 14:16, Nilay Shroff 写道:
> On 6/22/26 6:33 PM, Guixin Liu wrote:
>> Add a read-only "path_state" sysfs attribute to each NVMe path namespace
>> device (/sys/class/nvme/nvmeX/nvmeXcYnZ/path_state) that exposes whether
>> the path is currently enabled or disabled with a specific reason.
>>
>> The attribute reflects the result of nvme_path_is_disabled() checks:
>> - "enabled" : path is available for I/O
>> - "disabled (ctrl_down)" : controller is not live/deleting
>> - "disabled (ana_pending)" : ANA state change pending
>> - "disabled (ns_not_ready)" : namespace is not ready
>>
>> This gives userspace visibility into the multipath path selection state
>> without requiring users to piece together controller state and namespace
>> flags manually.
>>
>> Signed-off-by: Guixin Liu <kanie@linux.alibaba.com>
>> ---
>> v1->v2:
>> - Show specific disabled reason instead of just "disabled":
>> "disabled (ctrl_down)", "disabled (ana_pending)",
>> "disabled (ns_not_ready)". (Nilay Shroff)
>>
>> drivers/nvme/host/multipath.c | 16 ++++++++++++++++
>> drivers/nvme/host/nvme.h | 1 +
>> drivers/nvme/host/sysfs.c | 4 +++-
>> 3 files changed, 20 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/nvme/host/multipath.c
>> b/drivers/nvme/host/multipath.c
>> index 81fff2f20d23..5e3847fd6632 100644
>> --- a/drivers/nvme/host/multipath.c
>> +++ b/drivers/nvme/host/multipath.c
>> @@ -1210,6 +1210,22 @@ static ssize_t in_flight_bytes_show(struct
>> device *dev,
>> }
>> DEVICE_ATTR_RO(in_flight_bytes);
>> +static ssize_t path_state_show(struct device *dev,
>> + struct device_attribute *attr, char *buf)
>> +{
>> + struct nvme_ns *ns = nvme_get_ns_from_dev(dev);
>> + enum nvme_ctrl_state state = nvme_ctrl_state(ns->ctrl);
>> +
>> + if (state != NVME_CTRL_LIVE && state != NVME_CTRL_DELETING)
>> + return sysfs_emit(buf, "disabled (ctrl_down)\n");
>> + if (test_bit(NVME_NS_ANA_PENDING, &ns->flags))
>> + return sysfs_emit(buf, "disabled (ana_pending)\n");
>> + if (!test_bit(NVME_NS_READY, &ns->flags))
>> + return sysfs_emit(buf, "disabled (ns_not_ready)\n");
>> + return sysfs_emit(buf, "enabled\n");
>> +}
>> +DEVICE_ATTR_RO(path_state);
>> +
>
> I'd prefer not to open-code the path disabled checks in the sysfs
> attribute.
> Ideally, we could factor the logic into a helper that returns the path
> state
> (or disabled reason), and have nvme_path_is_disabled() built on top of
> that.
> This would keep the path selection logic and sysfs reporting in sync.
>
> The concern with the current implementation is that it duplicates the
> checks
> from nvme_path_is_disabled(). If someone updates the path disable
> criteria in
> the future, we'd also need to remember to update path_state_show().
> Having a
> common helper would avoid that.
>
> For instance, something like below:
>
> enum nvme_path_state {
> NVME_PATH_ENABLED,
> NVME_PATH_DISABLED_CTRL_DOWN,
> NVME_PATH_DISABLED_ANA_PENDING,
> NVME_PATH_DISABLED_NS_NOT_READY,
> };
>
> static enum nvme_path_state nvme_path_get_state(struct nvme_ns *ns)
> {
> enum nvme_ctrl_state state = nvme_ctrl_state(ns->ctrl);
>
> /*
> * We don't treat NVME_CTRL_DELETING as a disabled path as I/O should
> * still be able to complete assuming that the controller is
> connected.
> * Otherwise it will fail immediately and return to the requeue list.
> */
> if (state != NVME_CTRL_LIVE && state != NVME_CTRL_DELETING)
> return NVME_PATH_DISABLED_CTRL_DOWN;
>
> if (test_bit(NVME_NS_ANA_PENDING, &ns->flags))
> return NVME_PATH_DISABLED_ANA_PENDING;
>
> if (!test_bit(NVME_NS_READY, &ns->flags))
> return NVME_PATH_DISABLED_NS_NOT_READY;
>
> return NVME_PATH_ENABLED;
> }
>
> static bool nvme_path_is_disabled(struct nvme_ns *ns)
> {
> return nvme_path_get_state(ns) != NVME_PATH_ENABLED;
> }
>
> Now the existing callers can continue using nvme_path_is_disabled()
> as is without any change. But for sysfs, we'd call nvme_path_get_state().
> Then the sysfs would map enum nvme_path_state to strings and
> use it for output.
>
> static const char * const nvme_path_state_str[] = {
> [NVME_PATH_ENABLED] = "enabled",
> [NVME_PATH_DISABLED_CTRL_DOWN] = "disabled (ctrl_down)",
> [NVME_PATH_DISABLED_ANA_PENDING] = "disabled (ana_pending)",
> [NVME_PATH_DISABLED_NS_NOT_READY] = "disabled (ns_not_ready)",
> };
>
> ...
> return sysfs_emit(buf, "%s\n",
> nvme_path_state_str[nvme_path_get_state(ns)]);
>
> This way any future updates to the path disable logic would automatically
> be reflected in the sysfs output as well.
>
> Thanks,
> --Nilay
That's reasonable, will be changed in v3, thanks.
Best Regards,
Guixin Liu
next prev parent reply other threads:[~2026-06-23 7:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260622130318.2346995-1-kanie@linux.alibaba.com>
2026-06-23 6:16 ` [PATCH v2] nvme-multipath: expose path_state via sysfs Nilay Shroff
2026-06-23 7:54 ` Guixin Liu [this message]
2026-06-23 12:35 ` Keith Busch
2026-06-23 14:01 ` Nilay Shroff
2026-06-24 1:36 ` Guixin Liu
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=d34f4f41-fc35-4df9-b657-e84b520a6784@linux.alibaba.com \
--to=kanie@linux.alibaba.com \
--cc=axboe@kernel.dk \
--cc=dwagner@suse.de \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=nilay@linux.ibm.com \
--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