Re: [PATCH v4 2/2] nvme-multipath: add fail_if_no_path sysfs attribute

[Hannes Reinecke <hare@suse.de>]

On 10/1/26 11:48 AM, Krishna Iyer wrote:
> When no usable path exists, I/O on a multipath namespace is queued
> until a path returns. With ctrl_loss_tmo=-1 that can be forever:
> during a long fabric outage any process waiting on the I/O is stuck in
> D state. We hit this on virtualization hosts, where a SIGKILLed VM
> process cannot exit while draining I/O to an unreachable NVMe/TCP
> target.
> 
> Nothing can fail this I/O without tearing something down: controller
> deletion takes every namespace on the controller with it.
> 
> Add a fail_if_no_path attribute on the ns-head disk: a persistent
> per-namespace policy to fail parked and newly arriving I/O instead of
> queueing it when no usable path exists. It is the namespace-scoped
> counterpart to the controller-scoped fast_io_fail_tmo: the trigger is
> an event userspace observes (a consumer known to be gone, for us a
> SIGKILLed VM the host must reap), not a duration picked up front, and
> sibling namespaces behind the same controllers keep queueing and ride
> out the outage.
> 
> A CONNECTING controller stops counting as an available path, and with
> no controllers left the policy overrides the delayed_removal_secs
> queue-if-no-path window; the two are opposites, so fail_if_no_path takes
> precedence when both are set. ANA change and controller resetting still
> queue, since both are transient. Controller state is untouched and
> reconnects continue. Like dm's fail_if_no_path, the policy is transport
> agnostic.
> 
> Assisted-by: Claude:claude-fable-5
> Signed-off-by: Krishna Iyer <kiyer@crusoe.ai>
> ---
>   Documentation/ABI/stable/sysfs-nvme | 16 +++++++++
>   drivers/nvme/host/multipath.c       | 50 +++++++++++++++++++++++++++--
>   drivers/nvme/host/nvme.h            |  2 ++
>   drivers/nvme/host/sysfs.c           |  4 ++-
>   4 files changed, 69 insertions(+), 3 deletions(-)
> 
I do get the problem, but I think that 'fail_if_no_path' is a misnomer.
Problem is that we already have a 'QUEUE_IF_NO_PATH' setting, so 
'FAIL_IF_NO_PATH' really sounds like the inverstion of that.
Only that it isn't.
Maybe rename to 'FAIL_ON_CTRL_LOSS' to make it clear that the two 
settings really describe different use-cases?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
hare@suse.de                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich