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

Krishna Iyer kiyer at crusoe.ai
Sat Sep 5 21:22:35 PDT 2026


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.

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.

Thanks,
Krishna



More information about the Linux-nvme mailing list