On Fri, 2020-12-18 at 17:06 -0600, Benjamin Marzinski wrote: > I was asked to explain how checker_timeout works for checkers like > directio, that don't issue scsi commands with an explicit timeout > > Signed-off-by: Benjamin Marzinski <bmarzins@xxxxxxxxxx> > --- > multipath/multipath.conf.5 | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/multipath/multipath.conf.5 b/multipath/multipath.conf.5 > index ea66a01e..c7c4184b 100644 > --- a/multipath/multipath.conf.5 > +++ b/multipath/multipath.conf.5 > @@ -639,8 +639,13 @@ The default is: \fBno\fR > . > .TP > .B checker_timeout > -Specify the timeout to use for path checkers and prioritizers that > issue SCSI > -commands with an explicit timeout, in seconds. > +Specify the timeout to use for path checkers and prioritizers, in > seconds. > +Only prioritizers that issue scsi commands use checker_timeout. > Checkers > +that support an asynchronous mode (\fItur\fR and \fIdirectio\fR), > will > +return shortly after being called by multipathd, regardless of > whether the > +storage array responds. If the storage array hasn't responded, > mulitpathd will typo > +check for a response every second, until \fIchecker_timeout\fR > seconds have > +elapsed. This is a bit confusing IMHO. Most importantly, checkers will consider a path down if it doesn't respond to the checker command after the given timeout. The async behavior doesn't fit too well into this section. Maybe we should mention and explain the async property in the path_checkers section, and only refer to that here. (Btw is the directio checker still deprecated after all the work you recently put into it? The man page still says so). Regards, Martin -- Dr. Martin Wilck <mwilck@xxxxxxxx>, Tel. +49 (0)911 74053 2107 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg GF: Felix Imendörffer -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
