On Tue, Dec 07, 2021 at 09:11:55AM +0000, Martin Wilck wrote: > On Tue, 2021-12-07 at 09:19 +1000, Erwin van Londen wrote: > > Moreover, the existing marginal paths handler has two different modes > of operation, the "classical" one that disables reinstate, and the > more modern one that uses marginal pathgroups. I am wondering whether > we need the first mode in the long run. In particular if we want to > generalize this feature, we may want to get rind of the "classical" > mode altogether. I'm not aware of any distinct advantages of that > algorithm compared to marginal path groups. > > @Ben, Muneendra, what do you think? Sorry I missed this. I'm fine with deprecating the old style of handling marginal paths. > One word of caution here: we must be careful not to over-engineer. > As long as no other mechanism like FPIN for other transports is > conceivable, generalizing the concept makes only so much sense. > Therefore we shouldn't hold back the FPIN patches until we have > conceived of a generic mechanism, which may take a lot of time to > develop. If another mechanism becomes available, we could still try to > generalize the concept, if we keep the current additions clean and > well-separated from the core multipathd code. > > However I am really thrilled by the prospect of generalizing event > handling and reusing the uevent threads for FPIN. That would reduce > complexity a lot, which is a good thing IMO. > > @Ben, Muneendra, again, your opinions? I don't have a problem with that. Doing this does entwine a chunk of code that may not get frequently used to a chunk of code that is essential for multipathd to run correctly. But I guess if there are corner cases in the fpin code that cause issues for the rest of multipath, then either the fpin code gets used a lot and they are found quickly, or it doesn't, and they rarely cause problems. -Ben > Best > Martin > > > -- > dm-devel mailing list > dm-devel@xxxxxxxxxx > https://listman.redhat.com/mailman/listinfo/dm-devel -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
