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.
