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

Daniel Wagner dwagner at suse.de
Wed Jun 24 02:55:01 PDT 2026


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

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? 



More information about the Linux-nvme mailing list