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.
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 ?
Christophe
On Mon, Dec 14, 2020 at 10:39 AM Martin Wilck <mwilck@xxxxxxxx> wrote:
On Mon, 2020-12-14 at 08:56 +0100, Christophe Varoqui wrote:
> Hello,
>
> a user brought to my attention "multipathd show config | grep
> usock_timeout" does not agree with the default value stated in the
> manpage : 4000 instead of 1000.
>
> And indeed,
>
> ./libmpathcmd/mpath_cmd.h:#define DEFAULT_REPLY_TIMEOUT 4000
>
> Can you confirm this change is valid ?
Yes.
Reviewed-by: Martin Wilck <mwilck@xxxxxxxx>
You may want to add
Fixes: 7db0c44 ("multipathd: Set CLI timeout correctly")
because that commit changed the timeout without changing the man page.
Martin
>
> diff --git a/multipath/multipath.conf.5 b/multipath/multipath.conf.5
> index d2101ed6..7242d39b 100644
> --- a/multipath/multipath.conf.5
> +++ b/multipath/multipath.conf.5
> @@ -1153,7 +1153,7 @@ In these cases it is recommended to increase
> the CLI timeout to avoid
> those issues.
> .RS
> .TP
> -The default is: \fB1000\fR
> +The default is: \fB4000\fR
> .RE
> .
> .
>
> Best Regards,
> Christophe
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
