[PATCH] nvme-multipath: add fail_io_now sysfs attribute to fail queued I/O

[Sagi Grimberg]

On 06/09/2026 7:22, Krishna Iyer wrote:
> On 06/09/2026 1:36, Sagi Grimberg wrote:
>> I don't understand what is not sufficient with fast_io_fail_tmo? It would
>> determine the time that IO will fail when all paths are down.
> Thanks for taking a look, Sagi. fast_io_fail_tmo is indeed the closest
> existing knob. Like this patch, it fails the parked I/O without
> touching controller state. Three things make it unsuitable for this
> case though:
>
> 1. It cannot be engaged after the fact. nvme_start_failfast_work() has
> a single call site, the RESETTING -> CONNECTING transition in
> nvme_change_ctrl_state(), and it returns without scheduling if
> fast_io_fail_tmo is -1 at that instant. A controller in the reconnect
> loop stays in CONNECTING, and the sysfs store only updates opts, so
> once an outage has begun with failfast disabled there is no way to
> make the timer fire for that outage. That is exactly the situation in
> which the need for this arises.

At that point you can disconnect the controllers, which will teardown
the inflight blocked IO.

>
> 2. It decides based on time, and this decision is not about time. For
> deployments like ours the right policy for an outage of any length is
> to keep queueing; that is why we connect with ctrl_loss_tmo=-1 to
> begin with. The exception is not "the outage got long" but "this
> particular submitter was just killed and will never consume its
> completions", which host software learns at a moment no timer can
> anticipate. Any timeout short enough to release such I/O promptly
> would also fail I/O for every healthy workload whenever an ordinary
> outage outlasts it.
>
> 3. It is scoped to the controller. FAILFAST_EXPIRED marks the whole
> controller, so with all paths down it releases I/O for every namespace
> in the subsystem. The process being reaped owns exactly one namespace;
> the others belong to VMs that are still running and should keep
> queueing until the fabric heals.
>
> So fail_io_now is the failfast expiry made available on demand and per
> namespace: the same nvme_available_path() mechanism, and it likewise
> clears itself on reconnect, but it is triggered by the admin, for one
> volume, at the moment it is actually needed.
>
> Happy to work any of this into the changelog if that would help.

I am not sure I am following.

If you have a namespace that is attached to controllers say X,Y,Z,W
Now all of these controllers are unavailable, aren't all of the namespaces
on these paths also unavailable?

Or is it that the paths are online, but the ANA group got into a state where
there is no optimized path?