[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