[PATCH v3] nvme-multipath: expose path_state via sysfs
Guixin Liu
kanie at linux.alibaba.com
Wed Jun 24 04:52:48 PDT 2026
在 2026/6/24 17:55, Daniel Wagner 写道:
> On Wed, Jun 24, 2026 at 08:36:44AM +0100, John Garry wrote:
>> On 24/06/2026 06:48, 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 the
>>> current path state, including whether the path is enabled or disabled
>>> with a specific reason.
>>>
>>> Factor the path disable checks from nvme_path_is_disabled() into a new
>>> nvme_path_get_state() helper that returns an enum nvme_path_state. This
>>> keeps the path selection logic and sysfs reporting in sync, so any future
>>> updates to the path disable criteria are automatically reflected in the
>>> sysfs output.
>>>
>>> Possible values:
>>> - "enabled (optimized)" : ANA state is optimized
>>> - "enabled (non-optimized)" : ANA state is not optimized
>>> - "disabled (ctrl_down)" : controller is not live
>>> - "disabled (ana_pending)" : ANA state change pending
>>> - "disabled (ns_not_ready)" : namespace is not ready
> I'd prefer to have a single string here instead of something we might need
> to parse again. The sysfs docs says
>
> Mixing types, expressing multiple lines of data, and doing fancy
> formatting of data is heavily frowned upon. Doing these things may get
> you publicly humiliated and your code rewritten without notice.
>
> Something like
>
> - optimized
> - non-optimized
> - ctrl-down
> - ana-pending
> - ns-no-ready
Would this be redundant with ana_state?
Is this OK?
- enabled
- ctrl-down
- ana-pending
- ns-not-ready
CC Keith, John, Nilay, what do you think?
>
> BTW, the docs on sysfs say, these interfaces should be documented also
> in Documentation/ABI. So far we haven't done this for the nvme
> subsystem. Should we start with it?
Sure, just like the nvme-multipath.rst file I worked on earlier,
I can do this later with the help of AI.
Best Regards,
Guixin Liu
More information about the Linux-nvme
mailing list