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

[Nilay Shroff]

On 6/24/26 5:22 PM, Guixin Liu wrote:
> 
> 
> 在 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?

I tend to agree with Daniel about both mixing types and
reporting ana state values here as ana state is also reported
separately.

The purpose of path_state is really to expose whether the path
is currently eligible for path selection and, if not, why.

IMO, a simpler set of values which you suggested above
should be sufficient. But lets wait if Keith has any
other suggestion.

Thanks
--Nilay