On Fri, Dec 18, 2020 at 11:56:47PM +0000, Martin Wilck wrote: > 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. Sounds reasonable. > (Btw is the directio checker still deprecated after all the work you > recently put into it? The man page still says so). No. I'll change that. There are times when devices claim to be ready with the tur checker, when in truth, IO to them will fail. In these cases, the directio checker is the best way to avoid having paths bouncing up and down. -Ben > > 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
