Hello Martin, Muneendra.
As I kicked this discussion off in the beginning of the year and seeing the Muneendra and the broadcom people have come up with the first iteration I can only applaud the efforts. On behalf of all storage and linux administrators I would say "Thank you".
As for your remark Martin my view would be to try and create a modular approach where the transport layer drivers can hook into and inform multipathd of any event. The module in multipathd would then decide based on configured characteristics what the actions should be. (Take it offline, suspend for X amount of time, introduce X us delay etc...) That way when more transport methods are used these can then dynamically be linked into the configuration without having any impact on other parts of the transport stack. I can imagine that Infiniband. ethernet, SAS and others utilise different transport characteristics and as such may need to inform the attached hosts of one or more events. On FC this is FPIN but a similar module may be written for other transports.
Thanks
Erwin
On Mon, 2021-12-06 at 13:58 +0000, Martin Wilck wrote:
On Fri, 2021-12-03 at 18:02 +0100, Martin Wilck wrote:Rather than adding a new config option, I'd prefer to add a new value"fpin" to the marginal_pathgroups option. That would make it moreclearthat the two are actually related / exclusive.Another thought that occurred to me over the weekend: FPIN is fibre-channel only. What if someone has a mix of FC and other transports?Would it make sense to use FPIN for FC paths and "traditional" marginalpath detection for others? If yes, we'd need to change the logic andwe'd probably have to add a 4th mode ("fpin-mixed" or whatever).RegardsMartin--dm-devel mailing list
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
