[dm-devel] uxsock_timeout default value in man page

[Christophe Varoqui]

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 ?

Christophe


On Mon, Dec 14, 2020 at 10:39 AM Martin Wilck <mwilck at suse.com> 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 at suse.com>
>
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20201214/c5f5fda4/attachment.htm>