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

[Krishna Iyer]

On 9/10/26 2:00 AM, Nilay Shroff wrote:

> [...] 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. In v2 the check moves into the loop. With the policy set, a
path no longer counts as available if its controller is:

- CONNECTING: with ctrl_loss_tmo=-1 that is the entire outage. Same
  effect as FAILFAST_EXPIRED, policy-driven instead of timer-driven.

- LIVE with ANA inaccessible or persistent-loss: the target says no
  usable path, and today only controller deletion releases that I/O.

Everything else (RESETTING, ANA transitions) queues as before.

One interaction to call out: when all controllers are gone,
fail_if_no_path wins over the delayed_removal_secs queueing window --
an explicit fail policy beats a removal grace period. I'll document
that in the changelog.

> 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.

Ack, will keep it transport-agnostic in v2.

Thanks,
Krishna