Re: [PATCH v3] nvme-multipath: expose path_state via sysfs

[Guixin Liu <kanie@linux.alibaba.com>]

在 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