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

[Christoph Hellwig <hch@lst.de>]

On Tue, Apr 08, 2025 at 07:37:48PM +0530, Nilay Shroff wrote:
> >> +	 * For non-fabric controllers we support delayed removal of head disk
> >> +	 * node. If we reached up to here then it means that head disk is still
> >> +	 * alive and so we assume here that even if there's no path available
> >> +	 * maybe due to the transient link failure, we could queue up the IO
> >> +	 * and later when path becomes ready we re-submit queued IO.
> >> +	 */
> >> +	if (!(test_bit(NVME_NSHEAD_FABRICS, &head->flags)))
> >> +		return true;
> > 
> > Why is this conditional on fabrics or not?  The same rationale should
> > apply as much if not more for fabrics controllers.
> > 
> For fabrics we already have options like "reconnect_delay" and 
> "max_reconnects". So in case of fabric link failures, we delay 
> the removal of the head disk node based on those options.

Yes.  But having entirely different behavior for creating a multipath
node and removing it still seems like a rather bad idea.