* multipath.conf and polling_interval option seems misleading @ 2009-01-16 16:03 shane bradley 2009-01-16 16:10 ` Chandra Seetharaman 0 siblings, 1 reply; 7+ messages in thread From: shane bradley @ 2009-01-16 16:03 UTC (permalink / raw) To: dm-devel After reviewing the code and doing some testing I have noticed that polling_interval did not work as expected. I had reviewed the description of the option for multipath.conf and it conflicted with the results that I had got testing device-mapper-multipath on RHEL4/RHEL5. $ cat /usr/share/doc/device-mapper-multipath-0.4.7/multipath.conf.annotated # # name : polling_interval # # scope : multipathd # # desc : interval between two path checks in seconds # # default : 5 # # # polling_interval 10 --------- The behaviour that I had expected based on the option's description above: check path 1 wait polling_interval check path 2 wait polling_interval check path 1 wait polling_interval check path 2 wait polling_interval However after testing the results that I got was(with multipathd -v4): example: check path 1 check path 2 wait polling_interval check path 1 check path 2 wait polling_interval --------- The behaviour I seen in RHEL4 and RHEL5 was working as design after reviewing the code and talking to a couple engineers. The problem it seems is how I was reading the description of the option. From my results in testing and talking with some engineers the "polling_interval" option actually means: "The interval between checking all possible paths for all multipath paths" ---------- 1) Is my assumption correct that "polling_interval" actually means: "The interval between checking all possible paths for all multipath paths" 2) What is a better way to describe the "polling_interval" option? 3) Shouldn't we make it clearer for people who don't that that much experience with multipathing? --sbradley ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: multipath.conf and polling_interval option seems misleading 2009-01-16 16:03 multipath.conf and polling_interval option seems misleading shane bradley @ 2009-01-16 16:10 ` Chandra Seetharaman 2009-01-16 16:13 ` Bryn M. Reeves 2009-01-16 16:21 ` shane bradley 0 siblings, 2 replies; 7+ messages in thread From: Chandra Seetharaman @ 2009-01-16 16:10 UTC (permalink / raw) To: device-mapper development On Fri, 2009-01-16 at 11:03 -0500, shane bradley wrote: > After reviewing the code and doing some testing I have noticed that > polling_interval did not work as expected. > I had reviewed the description of the option for multipath.conf and it > conflicted with the results that I had got > testing device-mapper-multipath on RHEL4/RHEL5. > > $ cat /usr/share/doc/device-mapper-multipath-0.4.7/multipath.conf.annotated > # # name : polling_interval > # # scope : multipathd > # # desc : interval between two path checks in seconds > # # default : 5 > # # > # polling_interval 10 > > --------- > > The behaviour that I had expected based on the option's description above: > check path 1 > wait polling_interval > check path 2 > wait polling_interval > check path 1 > wait polling_interval > check path 2 > wait polling_interval > > However after testing the results that I got was(with multipathd -v4): > example: > check path 1 > check path 2 > wait polling_interval > check path 1 > check path 2 > wait polling_interval > > --------- > > The behaviour I seen in RHEL4 and RHEL5 was working as design after > reviewing the code and talking to a couple engineers. > > The problem it seems is how I was reading the description of the option. > From my results in testing and talking with some engineers the > "polling_interval" option actually means: > > "The interval between checking all possible paths for all multipath paths" > ---------- > > 1) Is my assumption correct that "polling_interval" actually means: > "The interval between checking all possible paths for all multipath paths" > > 2) What is a better way to describe the "polling_interval" option? > > 3) Shouldn't we make it clearer for people who don't that that much > experience with multipathing? IMO, the behavior seen is the proper behavior. If it does as per your interpretation, the seconds between checking of the same path will depend on the number of paths to a storage, which may not be acceptable. May be the wording in multipath.conf.annotated should be made clear. > --sbradley > > -- > dm-devel mailing list > dm-devel@redhat.com > https://www.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: multipath.conf and polling_interval option seems misleading 2009-01-16 16:10 ` Chandra Seetharaman @ 2009-01-16 16:13 ` Bryn M. Reeves 2009-01-16 18:34 ` Chandra Seetharaman 2009-01-16 16:21 ` shane bradley 1 sibling, 1 reply; 7+ messages in thread From: Bryn M. Reeves @ 2009-01-16 16:13 UTC (permalink / raw) To: sekharan, device-mapper development Chandra Seetharaman wrote: >> The behaviour I seen in RHEL4 and RHEL5 was working as design after >> reviewing the code and talking to a couple engineers. >> >> The problem it seems is how I was reading the description of the option. >> From my results in testing and talking with some engineers the >> "polling_interval" option actually means: >> >> "The interval between checking all possible paths for all multipath paths" >> ---------- >> >> 1) Is my assumption correct that "polling_interval" actually means: >> "The interval between checking all possible paths for all multipath paths" >> >> 2) What is a better way to describe the "polling_interval" option? >> >> 3) Shouldn't we make it clearer for people who don't that that much >> experience with multipathing? > > IMO, the behavior seen is the proper behavior. > > If it does as per your interpretation, the seconds between checking of > the same path will depend on the number of paths to a storage, which may > not be acceptable. > > May be the wording in multipath.conf.annotated should be made clear. Agreed - I'd not even really thought about this until Shane brought it up as I'd read the description to mean exactly what the code does. It does seem that some users are puzzled by this behaviour - can't hurt to make the wording a little more explicit for this option. Regards, Bryn. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: multipath.conf and polling_interval option seems misleading 2009-01-16 16:13 ` Bryn M. Reeves @ 2009-01-16 18:34 ` Chandra Seetharaman 0 siblings, 0 replies; 7+ messages in thread From: Chandra Seetharaman @ 2009-01-16 18:34 UTC (permalink / raw) To: bmr; +Cc: device-mapper development, sekharan On Fri, 2009-01-16 at 16:13 +0000, Bryn M. Reeves wrote: > Chandra Seetharaman wrote: <snip> > > > > May be the wording in multipath.conf.annotated should be made clear. > > Agreed - I'd not even really thought about this until Shane brought it > up as I'd read the description to mean exactly what the code does. me too. I couldn't read it otherwise. But, i suggested document change as the user is getting confused. > > It does seem that some users are puzzled by this behaviour - can't > hurt to make the wording a little more explicit for this option. > > Regards, > Bryn. > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: multipath.conf and polling_interval option seems misleading 2009-01-16 16:10 ` Chandra Seetharaman 2009-01-16 16:13 ` Bryn M. Reeves @ 2009-01-16 16:21 ` shane bradley 2009-01-29 16:21 ` shane bradley 1 sibling, 1 reply; 7+ messages in thread From: shane bradley @ 2009-01-16 16:21 UTC (permalink / raw) To: sekharan, device-mapper development Yeah the wording I think is the problem. Someone familiar with source code or multipathing will read that option differently. When someone reads the word path, they think of a single path to lun, then wait, check the next path to single lun. They are not thinking of all paths are checked at same time. After thinking about it, this would not be good behaviour because it could take forever (minutes) before a path is found dead. I think the problem is just the description of the option "polling_interval", it should be made clearer. --sbradley Chandra Seetharaman wrote: > On Fri, 2009-01-16 at 11:03 -0500, shane bradley wrote: > >> After reviewing the code and doing some testing I have noticed that >> polling_interval did not work as expected. >> I had reviewed the description of the option for multipath.conf and it >> conflicted with the results that I had got >> testing device-mapper-multipath on RHEL4/RHEL5. >> >> $ cat /usr/share/doc/device-mapper-multipath-0.4.7/multipath.conf.annotated >> # # name : polling_interval >> # # scope : multipathd >> # # desc : interval between two path checks in seconds >> # # default : 5 >> # # >> # polling_interval 10 >> >> --------- >> >> The behaviour that I had expected based on the option's description above: >> check path 1 >> wait polling_interval >> check path 2 >> wait polling_interval >> check path 1 >> wait polling_interval >> check path 2 >> wait polling_interval >> >> However after testing the results that I got was(with multipathd -v4): >> example: >> check path 1 >> check path 2 >> wait polling_interval >> check path 1 >> check path 2 >> wait polling_interval >> >> --------- >> >> The behaviour I seen in RHEL4 and RHEL5 was working as design after >> reviewing the code and talking to a couple engineers. >> >> The problem it seems is how I was reading the description of the option. >> From my results in testing and talking with some engineers the >> "polling_interval" option actually means: >> >> "The interval between checking all possible paths for all multipath paths" >> ---------- >> >> 1) Is my assumption correct that "polling_interval" actually means: >> "The interval between checking all possible paths for all multipath paths" >> >> 2) What is a better way to describe the "polling_interval" option? >> >> 3) Shouldn't we make it clearer for people who don't that that much >> experience with multipathing? >> > > IMO, the behavior seen is the proper behavior. > > If it does as per your interpretation, the seconds between checking of > the same path will depend on the number of paths to a storage, which may > not be acceptable. > > May be the wording in multipath.conf.annotated should be made clear. > > >> --sbradley >> >> -- >> dm-devel mailing list >> dm-devel@redhat.com >> https://www.redhat.com/mailman/listinfo/dm-devel >> > > -- > dm-devel mailing list > dm-devel@redhat.com > https://www.redhat.com/mailman/listinfo/dm-devel > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: multipath.conf and polling_interval option seems misleading 2009-01-16 16:21 ` shane bradley @ 2009-01-29 16:21 ` shane bradley 2009-01-29 16:44 ` Bryn M. Reeves 0 siblings, 1 reply; 7+ messages in thread From: shane bradley @ 2009-01-29 16:21 UTC (permalink / raw) To: device-mapper development [-- Attachment #1: Type: text/plain, Size: 3341 bytes --] Patch attached for updated wording of documentation on polling_interval. shane bradley wrote: > Yeah the wording I think is the problem. Someone familiar with source > code or multipathing will read that option differently. > > When someone reads the word path, they think of a single path to lun, > then wait, check the next path to single lun. > They are not thinking of all paths are checked at same time. > > After thinking about it, this would not be good behaviour because it > could take forever (minutes) before a path is found dead. > I think the problem is just the description of the option > "polling_interval", it should be made clearer. > > --sbradley > > Chandra Seetharaman wrote: >> On Fri, 2009-01-16 at 11:03 -0500, shane bradley wrote: >> >>> After reviewing the code and doing some testing I have noticed that >>> polling_interval did not work as expected. >>> I had reviewed the description of the option for multipath.conf and >>> it conflicted with the results that I had got >>> testing device-mapper-multipath on RHEL4/RHEL5. >>> >>> $ cat >>> /usr/share/doc/device-mapper-multipath-0.4.7/multipath.conf.annotated >>> # # name : polling_interval >>> # # scope : multipathd >>> # # desc : interval between two path checks in seconds >>> # # default : 5 >>> # # >>> # polling_interval 10 >>> >>> --------- >>> >>> The behaviour that I had expected based on the option's description >>> above: >>> check path 1 >>> wait polling_interval >>> check path 2 >>> wait polling_interval >>> check path 1 >>> wait polling_interval >>> check path 2 >>> wait polling_interval >>> >>> However after testing the results that I got was(with multipathd -v4): >>> example: >>> check path 1 >>> check path 2 >>> wait polling_interval >>> check path 1 >>> check path 2 >>> wait polling_interval >>> >>> --------- >>> >>> The behaviour I seen in RHEL4 and RHEL5 was working as design after >>> reviewing the code and talking to a couple engineers. >>> >>> The problem it seems is how I was reading the description of the >>> option. >>> From my results in testing and talking with some engineers the >>> "polling_interval" option actually means: >>> >>> "The interval between checking all possible paths for all multipath >>> paths" >>> ---------- >>> >>> 1) Is my assumption correct that "polling_interval" actually means: >>> "The interval between checking all possible paths for all multipath >>> paths" >>> >>> 2) What is a better way to describe the "polling_interval" option? >>> >>> 3) Shouldn't we make it clearer for people who don't that that much >>> experience with multipathing? >>> >> >> IMO, the behavior seen is the proper behavior. >> >> If it does as per your interpretation, the seconds between checking of >> the same path will depend on the number of paths to a storage, which may >> not be acceptable. >> >> May be the wording in multipath.conf.annotated should be made clear. >> >> >>> --sbradley >>> >>> -- >>> dm-devel mailing list >>> dm-devel@redhat.com >>> https://www.redhat.com/mailman/listinfo/dm-devel >>> >> >> -- >> dm-devel mailing list >> dm-devel@redhat.com >> https://www.redhat.com/mailman/listinfo/dm-devel >> > > -- > dm-devel mailing list > dm-devel@redhat.com > https://www.redhat.com/mailman/listinfo/dm-devel [-- Attachment #2: multipath.conf.annotated-polling_interval.patch --] [-- Type: text/plain, Size: 440 bytes --] --- multipath.conf.annotated.org 2009-01-29 11:03:22.000000000 -0500 +++ multipath.conf.annotated 2009-01-29 11:16:29.000000000 -0500 @@ -18,7 +18,8 @@ # # # # name : polling_interval # # scope : multipathd -# # desc : interval between two path checks in seconds +# # desc : the interval in seconds between polling all +# devices that compose up all multipath devices # # values : n > 0 # # default : 5 # # [-- Attachment #3: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: multipath.conf and polling_interval option seems misleading 2009-01-29 16:21 ` shane bradley @ 2009-01-29 16:44 ` Bryn M. Reeves 0 siblings, 0 replies; 7+ messages in thread From: Bryn M. Reeves @ 2009-01-29 16:44 UTC (permalink / raw) To: device-mapper development shane bradley wrote: > Patch attached for updated wording of documentation on polling_interval. Looks sane to me. Cheers, Bryn. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2009-01-29 16:44 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-01-16 16:03 multipath.conf and polling_interval option seems misleading shane bradley 2009-01-16 16:10 ` Chandra Seetharaman 2009-01-16 16:13 ` Bryn M. Reeves 2009-01-16 18:34 ` Chandra Seetharaman 2009-01-16 16:21 ` shane bradley 2009-01-29 16:21 ` shane bradley 2009-01-29 16:44 ` Bryn M. Reeves
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.