On Mon, 2020-12-14 at 11:19 +0100, Christophe Varoqui wrote: > Thank you for the review, the commit is in. > > the user reporting this, seems to face exactly the problem mentioned > in 7db0c44 : > > commit 7db0c4466c0e5ed2179710f93d1d14a0bf92922a > ... > And the default timeout should be increased to 4 seconds to > ensure > multipath runs correctly on large installations. > > He clearly qualifies as "large installation", and reach that timeout > when submitting a large number of mpathpersist registers in parallel > on boot. > Regardless, needing a uxsock_timeout greater than 4 seconds hints we > do something non-optimal there. > Have you already had a chance to investigate possible enhancements on > this ? Not yet. To solve this for good, I think we'd eventually need to tackle the BML (Big Multipathd Lock). Nobody has attempted to do this yet. Wrt to the special mpathpersist case, it would perhaps be possible to figure out some other optimization (first idea: rather than running dozens of mpathpersist processes during boot time, why not set the correct keys in the prkeys file right away?). We'd need to understand how they are using mpathpersist. That sounds like a case for the user's support team in the first place. Regards, Martin -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
