Hello Martin,
That is exactly the reason why we would need to modularise this. Access characteristics between different transport protocols can differ significantly and thus are susceptible to different indicators, tolerances and other variations that would need a different config setup. You don't really want to mix and match config options between the various options as that would significantly increase complexity and thus make the setup more errorprone. Things may often seem very clear cut from a develop(ers/ment) perspective however from a system administration side it gets often very confusing when even the smallest things start to contradict each other.
When tcp packets timeout from a iscsi based device we're 100% relying on tcp to sort itself out based on RTT values and slow start behaviour whereas FC is far more reliant on all upper levels from scsi/nvme-o-f side. These tolerances should be configurable independantly.
Regards
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
