[dm-devel] [PATCH] multipathd: handle fpin events

[Erwin van Londen]

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 more
> > clear
> > that 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"
> marginal
> path detection for others? If yes, we'd need to change the logic and
> we'd probably have to add a 4th mode ("fpin-mixed" or whatever).
> 
> Regards
> Martin
> 
> 
> 
> --
> dm-devel mailing list
> dm-devel at redhat.com
> https://listman.redhat.com/mailman/listinfo/dm-devel
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20211213/4ad92bd8/attachment.htm>