From patchwork Thu Jan 29 16:21:06 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: shane bradley X-Patchwork-Id: 4610 X-Patchwork-Delegate: christophe.varoqui@free.fr Received: from hormel.redhat.com (hormel1.redhat.com [209.132.177.33]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id n0TGO36V014433 for ; Thu, 29 Jan 2009 16:24:04 GMT Received: from listman.util.phx.redhat.com (listman.util.phx.redhat.com [10.8.4.110]) by hormel.redhat.com (Postfix) with ESMTP id EBBA78E0353; Thu, 29 Jan 2009 11:24:02 -0500 (EST) Received: from int-mx2.corp.redhat.com (nat-pool.util.phx.redhat.com [10.8.5.200]) by listman.util.phx.redhat.com (8.13.1/8.13.1) with ESMTP id n0TGN7hP020603 for ; Thu, 29 Jan 2009 11:23:07 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n0TGN6Tp004796 for ; Thu, 29 Jan 2009 11:23:07 -0500 Received: from mantra.usersys.redhat.com (dhcp243-61.rdu.redhat.com [10.11.243.61]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n0TGN6q4019693 for ; Thu, 29 Jan 2009 11:23:07 -0500 Message-ID: <4981D772.9090704@redhat.com> Date: Thu, 29 Jan 2009 11:21:06 -0500 From: shane bradley User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: device-mapper development Subject: Re: [dm-devel] multipath.conf and polling_interval option seems misleading References: <4970AFB8.6090906@redhat.com> <1232122255.29644.23.camel@chandra-ubuntu> <4970B41C.1000509@redhat.com> In-Reply-To: <4970B41C.1000509@redhat.com> X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26 X-loop: dm-devel@redhat.com X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.5 Precedence: junk Reply-To: device-mapper development List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com 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 --- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel --- 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 # #