Re: [RFC PATCHv3 1/3] nvme-multipath: introduce delayed removal of the multipath head node

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

On 5/8/25 11:03 AM, Christoph Hellwig wrote:
> On Thu, May 08, 2025 at 01:26:16AM +0530, Nilay Shroff wrote:
>> That's a possible approach; however, the challenge arises when the head node
>> points to multiple namespace paths, each associated with different fabric 
>> controllers.
> 
> That's generally a good point.  Especially PCIe vs fabrics will be
> fun to test.  We really need a PCI loop device for nvmet to be able
> to test it.
> 
>> As we know, max_reconnects is a per-controller attribute. So, if only one of
>> the fabric controllers has max_reconnects set to a non-zero value, but others
>> do not, how do we decide whether to implicitly disable head->delayed_removal_secs?
> 
> Well, as soon as something in the subsystems can't reconnect we want to
> delay the removal, right?
> 
Hmm, okay I agree (as you earlier suggested) lets not make any difference
between pcie vs fabric setup and unify both. If PCIe/fabric link fails to
reconnect and we lost all paths to a namespace then we'd start the head 
node's delayed_removal_secs timer. This way we'd not further complicate 
the logic and we also don't need to learn whether head node points to 
a fabric setup. I will spin a new patchset with this change and send 
upstream.

Thanks,
--Nilay