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

[Nilay Shroff <nilay@linux.ibm.com>]

On 9/10/26 7:24 AM, Krishna Iyer wrote:
> On 9/7/26 6:15 AM, Nilay Shroff wrote:
> 
>> Does the intention here is to force I/O to fail irrespective of the
>> controller state, or the intention here's to fail I/O only when no
>> usable path exist? If it's latter then I believe this is not the right
>> place to enforce this policy as since this check makes nvme_available_path()
>> return false unconditionally when NVME_NSHEAD_FAIL_IO_NOW is set, without
>> considering whether a usable path exists.
> 
> The latter. nvme_available_path() is only called once nvme_find_path()
> has come up empty, so the flag only decides whether pathless I/O is
> queued (default) or failed.
> 
Not always, nvme_available_path() could be also called in case
controller is resetting or controller is live but the ns/path ana
state is neither optimized nor non-optimized. So I think the policy
would be better enforced at the point where we have actually
determined that there is no usable path, rather than making
nvme_available_path() return false unconditionally when
fail_if_no_path is set.

> Agreed on the rename. For v2 I'll make fail_if_no_path a plain
> per-namespace policy: admin-set, no self-clearing, toggleable at any
> time including mid-outage.
> 
>> This attribute should be only exposed for fabric controller.
>> It looks this is being exported for non-fabric controller
>> as well. Moreover, I like attribute fail_if_no_path better
>> than fail_io_now, since it describes the actual policy being
>> enabled: when no usable path exists, fail I/O instead of
>> queueing it.
> 
> Right, v1 exposes it everywhere. Since v2 makes this a plain
> fail_if_no_path policy though, is fabric-only still what you'd want?
> The queue-vs-fail choice isn't fabric-specific: a PCIe head kept
> alive by delayed_removal_secs parks pathless I/O the same way, and
> dm's fail_if_no_path is transport-agnostic. If you'd still prefer
> fabric-only, I'll have the visibility callback check a sibling for
> NVME_F_FABRICS under head->srcu.
> 
For PCIe controllers, we don't have the same ctrl_loss_tmo/max_reconnects
semantics as fabrics, so initially I thought supporting fail_if_no_path only
for fabric controllers might make sense. However, looking at this again,
we already queue I/O when no usable path is available irrespective of the
transport. So I'm okay with keeping fail_if_no_path generic and transport-
agnostic. The policy is essentially about what to do when there is no
usable path i.e. fail the I/O or queue it— and that behavior isn't inherently
specific to fabrics.

Thanks,
--Nilay