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

在 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