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

Nilay Shroff nilay at linux.ibm.com
Wed May 7 12:56:16 PDT 2025



On 5/7/25 12:20 PM, Christoph Hellwig wrote:
> On Mon, May 05, 2025 at 08:39:11AM +0200, Hannes Reinecke wrote:
>>> +	if (ctrl->ops->flags & NVME_F_FABRICS)
>>> +		nvme_mpath_set_fabrics(head);
>>>   
>>
>> Please make this a separate patch.
> 
> Absolutelty not if we keep this, as there is no other user.
> 
> But I still don't like the fabrics special casing at all.
> 
> I'd much rather just disable it if opts is present and max_reconnects
> is set to non-0.
> 
That's a possible approach; however, the challenge arises when the head node
points to multiple namespace paths, each associated with different fabric 
controllers.
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?

In such case, should we assume that if any one of the controllers has max_reconnects
set to a non-zero value, then the configured head->delayed_removal_secs should be
ignored?

Thanks,
--Nilay



More information about the Linux-nvme mailing list