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

[Guixin Liu]

Hi Keith, gently ping.

Best Regards,
Guixin Liu

在 2026/7/7 09:47, Guixin Liu 写道:
>
>
> 在 2026/6/24 21:21, 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
>>
> Hi Keith, would you have any suggestions on this?
>
> Best Regards,
> Guixin Liu
>