diff mbox series

[2/2] multipath.conf(5): improve documentation of dev_loss_tmo

Message ID 20221201103238.2601-2-mwilck@suse.com (mailing list archive)
State Not Applicable, archived
Delegated to: christophe varoqui
Headers show
Series [1/2] multipath.conf(5): remove deprecated note for san_path_err algorithm | expand

Commit Message

Martin Wilck Dec. 1, 2022, 10:32 a.m. UTC 
From: Martin Wilck <mwilck@suse.com>

The statement that the default is 600 is wrong in most cases.
Improve the description of the default and the dependency of this
parameter on other parameters.

Signed-off-by: Martin Wilck <mwilck@suse.com>
Cc: Xose Vazquez Perez <xose.vazquez@gmail.com>
---
 multipath/multipath.conf.5 | 37 +++++++++++++++++++++++++------------
 1 file changed, 25 insertions(+), 12 deletions(-)

Comments

Xose Vazquez Perez Dec. 2, 2022, 5:31 p.m. UTC | #1 
On 12/1/22 11:32, mwilck@suse.com wrote:

> From: Martin Wilck <mwilck@suse.com>
> 
> The statement that the default is 600 is wrong in most cases.
> Improve the description of the default and the dependency of this
> parameter on other parameters.

I did change this patch to move "default value" to bottom.

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
Martin Wilck Dec. 2, 2022, 5:57 p.m. UTC | #2 
On Fri, 2022-12-02 at 18:31 +0100, Xose Vazquez Perez wrote:
> On 12/1/22 11:32, mwilck@suse.com wrote:
> 
> > From: Martin Wilck <mwilck@suse.com>
> > 
> > The statement that the default is 600 is wrong in most cases.
> > Improve the description of the default and the dependency of this
> > parameter on other parameters.
> 
> I did change this patch to move "default value" to bottom.

The problem is that there is no easily explained default value for this
parameter. Nice as the common "default value" format is, it doesn't
apply here.

If you have a suggestion for improving the formatting or wording,
please speak up.

Martin

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
Martin Wilck Dec. 2, 2022, 5:58 p.m. UTC | #3 
On Fri, 2022-12-02 at 18:57 +0100, Martin Wilck wrote:
> On Fri, 2022-12-02 at 18:31 +0100, Xose Vazquez Perez wrote:
> > On 12/1/22 11:32, mwilck@suse.com wrote:
> > 
> > > From: Martin Wilck <mwilck@suse.com>
> > > 
> > > The statement that the default is 600 is wrong in most cases.
> > > Improve the description of the default and the dependency of this
> > > parameter on other parameters.
> > 
> > I did change this patch to move "default value" to bottom.
> 
> The problem is that there is no easily explained default value for
> this
> parameter. Nice as the common "default value" format is, it doesn't
> apply here.
> 
> If you have a suggestion for improving the formatting or wording,
> please speak up.

Sorry, I missed your other email because it had been sorted into a
different folder.

Martin

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
Roger Heflin Dec. 2, 2022, 8:48 p.m. UTC | #4 
Reading through it, on the line below, shouldn't it be -t (not -T)?

Line:
+the multipath-tools built-in settings override the default. Run
\fImultipath -T\fR

On Fri, Dec 2, 2022 at 11:58 AM Martin Wilck <mwilck@suse.com> wrote:

> On Fri, 2022-12-02 at 18:57 +0100, Martin Wilck wrote:
> > On Fri, 2022-12-02 at 18:31 +0100, Xose Vazquez Perez wrote:
> > > On 12/1/22 11:32, mwilck@suse.com wrote:
> > >
> > > > From: Martin Wilck <mwilck@suse.com>
> > > >
> > > > The statement that the default is 600 is wrong in most cases.
> > > > Improve the description of the default and the dependency of this
> > > > parameter on other parameters.
> > >
> > > I did change this patch to move "default value" to bottom.
> >
> > The problem is that there is no easily explained default value for
> > this
> > parameter. Nice as the common "default value" format is, it doesn't
> > apply here.
> >
> > If you have a suggestion for improving the formatting or wording,
> > please speak up.
>
> Sorry, I missed your other email because it had been sorted into a
> different folder.
>
> Martin
>
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://listman.redhat.com/mailman/listinfo/dm-devel
>
>
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
Martin Wilck Dec. 2, 2022, 10:49 p.m. UTC | #5 
On Fri, 2022-12-02 at 14:48 -0600, Roger Heflin wrote:
> Reading through it, on the line below, shouldn't it be -t (not -T)?
> 

No, -T is correct. -t prints the entire internal table, most of which
doesn't apply on any given system. -T prints only the settings for
hardware that's present in the given system, which is what most users
will prefer (I assume).

But thanks for reading carefully. Appreciated!

Martin



> Line:
> +the multipath-tools built-in settings override the default. Run
> \fImultipath -T\fR
> 
> On Fri, Dec 2, 2022 at 11:58 AM Martin Wilck <mwilck@suse.com> wrote:
> > On Fri, 2022-12-02 at 18:57 +0100, Martin Wilck wrote:
> > > On Fri, 2022-12-02 at 18:31 +0100, Xose Vazquez Perez wrote:
> > > > On 12/1/22 11:32, mwilck@suse.com wrote:
> > > > 
> > > > > From: Martin Wilck <mwilck@suse.com>
> > > > > 
> > > > > The statement that the default is 600 is wrong in most cases.
> > > > > Improve the description of the default and the dependency of
> > > > > this
> > > > > parameter on other parameters.
> > > > 
> > > > I did change this patch to move "default value" to bottom.
> > > 
> > > The problem is that there is no easily explained default value
> > > for
> > > this
> > > parameter. Nice as the common "default value" format is, it
> > > doesn't
> > > apply here.
> > > 
> > > If you have a suggestion for improving the formatting or wording,
> > > please speak up.
> > 
> > Sorry, I missed your other email because it had been sorted into a
> > different folder.
> > 
> > Martin
> > 
> > --
> > dm-devel mailing list
> > dm-devel@redhat.com
> > https://listman.redhat.com/mailman/listinfo/dm-devel
> > 

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
Roger Heflin Dec. 2, 2022, 11:44 p.m. UTC | #6 
Thanks.

The older distribution I checked has this for -T
     -T tm:valid
              check if tm matches the multipathd configuration timestamp
value from /run/multipathd/timestamp If so, return success if valid is 1.
Otherwise, return failure. If the timestamp doesn't match continue with
multipath execution.  This option is designed to be used with -c by the
udev rules.

So really weird option.

On Fri, Dec 2, 2022 at 4:49 PM Martin Wilck <mwilck@suse.com> wrote:

> On Fri, 2022-12-02 at 14:48 -0600, Roger Heflin wrote:
> > Reading through it, on the line below, shouldn't it be -t (not -T)?
> >
>
> No, -T is correct. -t prints the entire internal table, most of which
> doesn't apply on any given system. -T prints only the settings for
> hardware that's present in the given system, which is what most users
> will prefer (I assume).
>
> But thanks for reading carefully. Appreciated!
>
> Martin
>
>
>
> > Line:
> > +the multipath-tools built-in settings override the default. Run
> > \fImultipath -T\fR
> >
> > On Fri, Dec 2, 2022 at 11:58 AM Martin Wilck <mwilck@suse.com> wrote:
> > > On Fri, 2022-12-02 at 18:57 +0100, Martin Wilck wrote:
> > > > On Fri, 2022-12-02 at 18:31 +0100, Xose Vazquez Perez wrote:
> > > > > On 12/1/22 11:32, mwilck@suse.com wrote:
> > > > >
> > > > > > From: Martin Wilck <mwilck@suse.com>
> > > > > >
> > > > > > The statement that the default is 600 is wrong in most cases.
> > > > > > Improve the description of the default and the dependency of
> > > > > > this
> > > > > > parameter on other parameters.
> > > > >
> > > > > I did change this patch to move "default value" to bottom.
> > > >
> > > > The problem is that there is no easily explained default value
> > > > for
> > > > this
> > > > parameter. Nice as the common "default value" format is, it
> > > > doesn't
> > > > apply here.
> > > >
> > > > If you have a suggestion for improving the formatting or wording,
> > > > please speak up.
> > >
> > > Sorry, I missed your other email because it had been sorted into a
> > > different folder.
> > >
> > > Martin
> > >
> > > --
> > > dm-devel mailing list
> > > dm-devel@redhat.com
> > > https://listman.redhat.com/mailman/listinfo/dm-devel
> > >
>
>
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
Martin Wilck Dec. 2, 2022, 11:50 p.m. UTC | #7 
On Fri, 2022-12-02 at 17:44 -0600, Roger Heflin wrote:
> Thanks.
> 
> The older distribution I checked has this for -T
>      -T tm:valid
>               check if tm matches the multipathd configuration
> timestamp value from /run/multipathd/timestamp If so, return success
> if valid is 1. Otherwise, return failure. If the timestamp doesn't
> match continue with multipath execution.  This option is designed to
> be used with -c by the udev rules.

Strange, I can't find this anywhere in the sources I know.
What distro is this? "multipath -T" in the sense I described has
existed since 0.7.7, so for more than 4 years.

Martin

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
Xose Vazquez Perez Dec. 3, 2022, midnight UTC | #8 
On 12/3/22 00:50, Martin Wilck wrote:

> On Fri, 2022-12-02 at 17:44 -0600, Roger Heflin wrote:
>> Thanks.
>>
>> The older distribution I checked has this for -T
>>       -T tm:valid
>>                check if tm matches the multipathd configuration
>> timestamp value from /run/multipathd/timestamp If so, return success
>> if valid is 1. Otherwise, return failure. If the timestamp doesn't
>> match continue with multipath execution.  This option is designed to
>> be used with -c by the udev rules.
> 
> Strange, I can't find this anywhere in the sources I know.
> What distro is this? "multipath -T" in the sense I described has
> existed since 0.7.7, so for more than 4 years.

RH: https://src.fedoraproject.org/rpms/device-mapper-multipath/blob/6738b34a0b0aabf1bc8c15d540bafa29ca99c58f/f/0158-RHBZ-1318581-timestamp-doc-fix.patch

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
Roger Heflin Dec. 3, 2022, midnight UTC | #9 
One of the Enterprise 7 variants, Claims "0.4.9" multipath but appears to
have a number of recent features backported, so some frankensteined version.

On Fri, Dec 2, 2022 at 5:50 PM Martin Wilck <mwilck@suse.com> wrote:

> On Fri, 2022-12-02 at 17:44 -0600, Roger Heflin wrote:
> > Thanks.
> >
> > The older distribution I checked has this for -T
> >      -T tm:valid
> >               check if tm matches the multipathd configuration
> > timestamp value from /run/multipathd/timestamp If so, return success
> > if valid is 1. Otherwise, return failure. If the timestamp doesn't
> > match continue with multipath execution.  This option is designed to
> > be used with -c by the udev rules.
>
> Strange, I can't find this anywhere in the sources I know.
> What distro is this? "multipath -T" in the sense I described has
> existed since 0.7.7, so for more than 4 years.
>
> Martin
>
>
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
Martin Wilck Dec. 3, 2022, 12:02 a.m. UTC | #10 
On Fri, 2022-12-02 at 18:00 -0600, Roger Heflin wrote:
> One of the Enterprise 7 variants, Claims "0.4.9" multipath but
> appears to have a number of recent features backported, so some
> frankensteined version.
> 
> On Fri, Dec 2, 2022 at 5:50 PM Martin Wilck <mwilck@suse.com> wrote:
> > On Fri, 2022-12-02 at 17:44 -0600, Roger Heflin wrote:
> > > Thanks.
> > > 
> > > The older distribution I checked has this for -T
> > >      -T tm:valid
> > >               check if tm matches the multipathd configuration
> > > timestamp value from /run/multipathd/timestamp If so, return
> > > success
> > > if valid is 1. Otherwise, return failure. If the timestamp
> > > doesn't
> > > match continue with multipath execution.  This option is designed
> > > to
> > > be used with -c by the udev rules.
> > 
> > Strange, I can't find this anywhere in the sources I know.
> > What distro is this? "multipath -T" in the sense I described has
> > existed since 0.7.7, so for more than 4 years.
> > 
> > Martin
> > 

Funny, Ben never told me there was a conflicting option name in RHEL.
I guess it's too late now, as I said, the upstream option has existed
for 4 years.

Martin

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
Xose Vazquez Perez Dec. 3, 2022, 12:14 a.m. UTC | #11 
On 12/3/22 01:02, Martin Wilck wrote:

> Funny, Ben never told me there was a conflicting option name in RHEL.
> I guess it's too late now, as I said, the upstream option has existed
> for 4 years.

Because it was remove in RHEL-8, since multipath-tools were updated to 0.8.4
RHEL-7 uses a very old code base(0.4.9) with a lot of patches(273)

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
Roger Heflin Dec. 3, 2022, 12:19 a.m. UTC | #12 
Enterprise 8 seems to have the new -T option, so clearly the old option had
limited use, and went away.

I had to read the updates to make sure I was not missing anything in my
understanding of that timeout.    We override the vendors setting on a
number of arrays (we use 87400 seconds, long enough that the paths stay
around for normal array work-fw updates and reboot but short enough the
paths go away if really gone).    We have a very large footprint of arrays
and hosts so have a lot of operational experience debugging issues caused
by poor defaults interacting ( multipath, scsi, cluster,  and applications
timeouts).

On Fri, Dec 2, 2022 at 4:49 PM Martin Wilck <mwilck@suse.com> wrote:

> On Fri, 2022-12-02 at 14:48 -0600, Roger Heflin wrote:
> > Reading through it, on the line below, shouldn't it be -t (not -T)?
> >
>
> No, -T is correct. -t prints the entire internal table, most of which
> doesn't apply on any given system. -T prints only the settings for
> hardware that's present in the given system, which is what most users
> will prefer (I assume).
>
> But thanks for reading carefully. Appreciated!
>
> Martin
>
>
>
> > Line:
> > +the multipath-tools built-in settings override the default. Run
> > \fImultipath -T\fR
> >
> > On Fri, Dec 2, 2022 at 11:58 AM Martin Wilck <mwilck@suse.com> wrote:
> > > On Fri, 2022-12-02 at 18:57 +0100, Martin Wilck wrote:
> > > > On Fri, 2022-12-02 at 18:31 +0100, Xose Vazquez Perez wrote:
> > > > > On 12/1/22 11:32, mwilck@suse.com wrote:
> > > > >
> > > > > > From: Martin Wilck <mwilck@suse.com>
> > > > > >
> > > > > > The statement that the default is 600 is wrong in most cases.
> > > > > > Improve the description of the default and the dependency of
> > > > > > this
> > > > > > parameter on other parameters.
> > > > >
> > > > > I did change this patch to move "default value" to bottom.
> > > >
> > > > The problem is that there is no easily explained default value
> > > > for
> > > > this
> > > > parameter. Nice as the common "default value" format is, it
> > > > doesn't
> > > > apply here.
> > > >
> > > > If you have a suggestion for improving the formatting or wording,
> > > > please speak up.
> > >
> > > Sorry, I missed your other email because it had been sorted into a
> > > different folder.
> > >
> > > Martin
> > >
> > > --
> > > dm-devel mailing list
> > > dm-devel@redhat.com
> > > https://listman.redhat.com/mailman/listinfo/dm-devel
> > >
>
>
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
Benjamin Marzinski Dec. 5, 2022, 11:22 p.m. UTC | #13 
On Sat, Dec 03, 2022 at 01:02:41AM +0100, Martin Wilck wrote:
> On Fri, 2022-12-02 at 18:00 -0600, Roger Heflin wrote:
> > One of the Enterprise 7 variants, Claims "0.4.9" multipath but
> > appears to have a number of recent features backported, so some
> > frankensteined version.
> > 
> > On Fri, Dec 2, 2022 at 5:50 PM Martin Wilck <mwilck@suse.com> wrote:
> > > On Fri, 2022-12-02 at 17:44 -0600, Roger Heflin wrote:
> > > > Thanks.
> > > > 
> > > > The older distribution I checked has this for -T
> > > >      -T tm:valid
> > > >               check if tm matches the multipathd configuration
> > > > timestamp value from /run/multipathd/timestamp If so, return
> > > > success
> > > > if valid is 1. Otherwise, return failure. If the timestamp
> > > > doesn't
> > > > match continue with multipath execution.  This option is designed
> > > > to
> > > > be used with -c by the udev rules.
> > > 
> > > Strange, I can't find this anywhere in the sources I know.
> > > What distro is this? "multipath -T" in the sense I described has
> > > existed since 0.7.7, so for more than 4 years.
> > > 
> > > Martin
> > > 
> 
> Funny, Ben never told me there was a conflicting option name in RHEL.
> I guess it's too late now, as I said, the upstream option has existed
> for 4 years.

This was a fix for a RHEL specific systemd issue, that's long since been
resolved in more up to date versions of RHEL. RHEL-8 and RHEL-9 have the
same code as upstream for the -T option.

-Ben

> 
> Martin
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
diff mbox series

Patch

diff --git a/multipath/multipath.conf.5 b/multipath/multipath.conf.5
index 41a0112..fc7434c 100644
--- a/multipath/multipath.conf.5
+++ b/multipath/multipath.conf.5
@@ -707,21 +707,34 @@  The default is: \fB5\fR
 .
 .TP
 .B dev_loss_tmo
-Specify the number of seconds the SCSI layer will wait after a problem has
-been detected on a FC remote port before removing it from the system. This
-can be set to "infinity" which sets it to the max value of 2147483647
-seconds, or 68 years. It will be automatically adjusted to the overall
-retry interval \fIno_path_retry\fR * \fIpolling_interval\fR
-if a number of retries is given with \fIno_path_retry\fR and the
-overall retry interval is longer than the specified \fIdev_loss_tmo\fR value.
-The Linux kernel will cap this value to \fI600\fR if \fIfast_io_fail_tmo\fR
-is not set. See KNOWN ISSUES.
+Specify the number of seconds the SCSI layer will wait after a connection loss has
+been detected on a remote port before removing it from the system. This
+can be set to "infinity", which effectively means 136 years (2^32-1 seconds).
+This parameter is only applied to Fibre Channel and SAS devices.
 .RS
-.TP
-The default is: \fB600\fR
+.LP
+The value of \fIdev_loss_tmo\fR is restricted by other settings.
+If \fIfast_io_fail_tmo\fR is set to a positive value,
+.B multipathd
+will make sure that the value of \fIdev_loss_tmo\fR is larger than
+\fIno_path_retry\fR * \fIpolling_interval\fR.
+If \fIfast_io_fail_tmo\fR is not set, the kernel limits the \fIdev_loss_tmo\fR
+value to 600 seconds.
+In this case, the user has to make sure that \fIno_path_retry\fR is smaller
+than \fIdev_loss_tmo / polling_interval\fR. In particular,
+\fIno_path_retry\fR must not be set to \(dq\fIqueue\fR\(dq. See KNOWN ISSUES.
+.LP
+When path devices reappear after a connection loss, it is much easier for
+the kernel to simply reactivate an inactive device than to re-add
+a previously deleted one. It is therefore recommended to set
+\fIdev_loss_tmo\fR to a large value within the restrictions mentioned above.
+.LP
+The default is: \fBhardware dependent\fR. Fibre Channel and SAS devices have
+hardware-dependent defaults, which are left unchanged if \fIdev_loss_tmo\fR is
+not specified. For a few storage arrays, the multipath-tools built-in settings
+override the default. Run \fImultipath -T\fR to see the settings for your device.
 .RE
 .
-.
 .TP
 .B eh_deadline
 Specify the maximum number of seconds the SCSI layer will spend doing error