Re: [PATCH v3] nvme-multipath: add fail_if_no_path sysfs attribute

[Keith Busch <kbusch@kernel.org>]

On Wed, Sep 23, 2026 at 03:57:53PM -0700, Krishna Iyer wrote:
> On 9/23/26 2:48 PM, Keith Busch wrote:
> > I agree with Hannes that we shouldn't need a new flag for this. The
> > current behavior is just broken in a few ways.
> >
> > We just need to restrict queue_if_no_path to only if there really are no
> > paths so that we actually respect the failfast_tmo.
> >
> > And the ANA inaccessible and persistent-loss handling you introduced
> > here should just be the default without requiring a flag. But I think
> > you need to add a requeue_list kick in nvme_update_ns_ana_state() too in
> > case the ANA transition leaves the namespace inaccessible.
> 
> Agreed those are real problems, but fixing them still leaves no way
> to cover this case. Subsystems commonly expose many volumes as
> namespaces behind the same controllers, and failfast is controller
> scoped and time based: a timeout fails every namespace or none, and
> the trigger here is an event, not a duration one can pick up front,
> while sibling namespaces should keep queueing and ride out the
> outage. delayed_removal_secs does not apply either: it only governs
> the window after the last path is removed (here the controllers still
> exist and keep reconnecting), and its expiry removes the head disk,
> where this case needs the opposite, fail the parked I/O and keep the
> device. fail_if_no_path stays the only namespace scoped way to
> release parked I/O.

I get that failfast is at the controller scope, but that seems okay:
when the transport is down, every namespace behind that controller is
equally without a path. When the controller is live, the per-namespace
inaccessible case is handled separately by the ANA state, so namespace
heads that lose access bail and the rest can carry on.

Is your intention to have some namespaces wait for reconnect longer than
others?