[dm-devel] multipath.conf and polling_interval option seems misleading

[shane bradley]

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 at redhat.com
>>> https://www.redhat.com/mailman/listinfo/dm-devel
>>>     
>>
>> -- 
>> dm-devel mailing list
>> dm-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/dm-devel
>>   
>
> -- 
> dm-devel mailing list
> dm-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: multipath.conf.annotated-polling_interval.patch
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20090129/74be4139/attachment.ksh>