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

[Nilay Shroff]

On 10/2/26 4:26 PM, Krishna Iyer wrote:
> On 10/2/26 11:39 AM, Hannes Reinecke wrote:
> > 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?
>
> Agreed, and thanks. You are right that fail_if_no_path reads as the
> inverse of queue_if_no_path when it is not, and the v4 split makes that
> clearer. Patch 1 now fails the cases where a path exists but cannot
> serve I/O, so the only thing this attribute still does is stop waiting
> for a controller that is gone or reconnecting. I am happy to rename it,
> and fail_on_ctrl_loss describes that well.
>
> One piece of history worth surfacing first. The fail_if_no_path name was
> Nilay's suggestion in v2, so I would request we settle on one name you
> both agree on rather than change it twice. Nilay, does fail_on_ctrl_loss
> work for you?
> Yes, I also like fail_on_ctrl_loss as Hannes suggested.

The earlier fail_if_no_path name came from the dm-multipath policy, which
uses the same name for a similar use case. However, I agree that fail_if_no_path
could be misleading here since it sounds like the inverse of QUEUE_IF_NO_PATH.

So I'd vote for fail_on_ctrl_loss for this change.

Thanks,
--Nilay