| Message ID | CABr-GnfTqde6t2LFTHbrRkp1qMVbsRUEFBqU6tW1M_uR1svHFg@mail.gmail.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | christophe varoqui |
| Headers | show |
| Series | uxsock_timeout default value in man page | expand |
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@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 -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
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@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@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
>
>
>
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
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@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
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 .