<div dir="ltr"><div>Enterprise 8 seems to have the new -T option, so clearly the old option had limited use, and went away.</div><div><br></div><div>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).<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 2, 2022 at 4:49 PM Martin Wilck <<a href="mailto:mwilck@suse.com" target="_blank">mwilck@suse.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 2022-12-02 at 14:48 -0600, Roger Heflin wrote:<br>
> Reading through it, on the line below, shouldn't it be -t (not -T)?<br>
> <br>
<br>
No, -T is correct. -t prints the entire internal table, most of which<br>
doesn't apply on any given system. -T prints only the settings for<br>
hardware that's present in the given system, which is what most users<br>
will prefer (I assume).<br>
<br>
But thanks for reading carefully. Appreciated!<br>
<br>
Martin<br>
<br>
<br>
<br>
> Line:<br>
> +the multipath-tools built-in settings override the default. Run<br>
> \fImultipath -T\fR<br>
> <br>
> On Fri, Dec 2, 2022 at 11:58 AM Martin Wilck <<a href="mailto:mwilck@suse.com" target="_blank">mwilck@suse.com</a>> wrote:<br>
> > On Fri, 2022-12-02 at 18:57 +0100, Martin Wilck wrote:<br>
> > > On Fri, 2022-12-02 at 18:31 +0100, Xose Vazquez Perez wrote:<br>
> > > > On 12/1/22 11:32, <a href="mailto:mwilck@suse.com" target="_blank">mwilck@suse.com</a> wrote:<br>
> > > > <br>
> > > > > From: Martin Wilck <<a href="mailto:mwilck@suse.com" target="_blank">mwilck@suse.com</a>><br>
> > > > > <br>
> > > > > The statement that the default is 600 is wrong in most cases.<br>
> > > > > Improve the description of the default and the dependency of<br>
> > > > > this<br>
> > > > > parameter on other parameters.<br>
> > > > <br>
> > > > I did change this patch to move "default value" to bottom.<br>
> > > <br>
> > > The problem is that there is no easily explained default value<br>
> > > for<br>
> > > this<br>
> > > parameter. Nice as the common "default value" format is, it<br>
> > > doesn't<br>
> > > apply here.<br>
> > > <br>
> > > If you have a suggestion for improving the formatting or wording,<br>
> > > please speak up.<br>
> > <br>
> > Sorry, I missed your other email because it had been sorted into a<br>
> > different folder.<br>
> > <br>
> > Martin<br>
> > <br>
> > --<br>
> > dm-devel mailing list<br>
> > <a href="mailto:dm-devel@redhat.com" target="_blank">dm-devel@redhat.com</a><br>
> > <a href="https://listman.redhat.com/mailman/listinfo/dm-devel" rel="noreferrer" target="_blank">https://listman.redhat.com/mailman/listinfo/dm-devel</a><br>
> > <br>
<br>
</blockquote></div>