On Mon, 2025-12-08 at 15:50 -0500, Benjamin Marzinski wrote: > On Mon, Dec 08, 2025 at 03:46:56PM +0100, Martin Wilck wrote: > > > > I may be missing something, but this is quite a lot of additional > > complexity just for the shortcut. Have you considered just not > > taking > > the shortcut in the first place? > > Yep. But that means that whenever you register a multipath device > with > mpathpersist, multipathd will (almost always pointlessly) re-register > all the paths, just to make sure it doesn't hit these super rare > corner > cases. So this added complexity keeps multipathd from running > unnecesary > scsi PR commands, and should be quicker. All multipathd does is break > the new cli message up into pathnames, and then has > pr_register_active_paths() check the paths against the pathanames, > and > skip them if they match and the number of keys is as big as expected > (and it needs to check the number of keys regardless of whether it > uses > the shortcut). > > I thought briefly about pulling all the path registration work into > multipathd, but it ends up making multipathd even more complex than > this > shortcut, while not saving much complexity from libmpathpersist. If > we > wanted to make multipathd handle all of libmpathpersists work, that > would be a different story, but I'm still not sold on the idea of > doing > that. > > That being said, we can drop a chunk of code if we just force > multipathd to automatically reregister the paths. So if you think > that > the reduced work is not worth the added complexity, I'm o.k. with > pulling the shortcut out completely.
I admit I am somewhat intimidated by the complexity into which the PR code has grown. Therefore I would be glad to avoid extra complexity if possible. But for that very reason, I don't feel competent to judge whether this complexity is "worth" it, IOW how badly performance would be affected by the extra register commands, in particular during high IO load. I suppose it's not so much a matter of "performance", rather of latency between running mpathpersist and the completion of the task in multipathd, which might be critical in certain situations. This is why I wrote "have you considered". If you, from the vast exprience that you gained in the course of your recent work, think that this extra complexity is worth it, fine with me. I'll go over the patch once more. Martin
