[dm-devel] HSG80, DM, multipath issues

[Christophe Varoqui]

D. North a écrit :
> Thus spake Christophe Varoqui (christophe.varoqui at free.fr):
>
>   
>> The one I used is "force a bounce per LUN just after driver loading", 
>> which this snippet does :
>>
>>        sg_start -s 1 /dev/$i
>>     
>
>
> Thanks! ... This got me going enough to get a /dev/mapper/lun4p1...p3 up & running!
> This was done manually from a 'rescue mode' boot of SuSE 10.
>
> After trying the required commands on a running system, it's clear now that the
> device mapper setup has to be done in the initrd if I expect to boot from this
> array. No problem there... that's just a comment.
>
> What is troubling me more at the moment is the difference between the device
> mapper table setup commands created by the multipath command and how they
> are different from what dm-mpath.c is actually expecting.
>
> I downloaded 0.4.7 multipath tools & verified that they produce the same
> table setup issues that I'm having trouble with from the 0.4.5 tool that
> is current with SuSE 10. For example, the SuSE version of multipath command
> produces this:
>        0 443027195 multipath 0 0 2 1 round-robin 1 1 8:0 1000 round-robin 1 1 8:16 1000
> Which produces the previously mentioned misparse in dm-mpath.c (my debugging mods)
>        Apr 10 15:30:35 orthus-san kernel: nr_params is 1001, nr_selector_args = 1000, pg->nr_pgpaths is 8
>
> Multipath tools 0.4.7 also causes the same diagnostic message (from my
> debugging modifications), and it is sending in the same number of arguments
> (14) to dm-mpath.c.  I don't, however, get the diagnostic message any more from
> this version of multipath to determine what it is actually sending into
> libdevmapper, so I am not, at the moment, absolutely certain that the argument
> list is the same as 0.4.5.
>
> To bypass the misparse, I can still use a command like this:
>        # echo 0 443027195 multipath 0 0 2 1 round-robin 1 1 1 0 8:0 round-robin 1 1 1 0 8:16 | dmsetup create lun4
>
> I have successfully set up a device mapper mapping that I can read & write
> to from a rescue system, so the above command does actually work.
>
> Unfortunately, if I correctly understand what I'm seeing, this means that the
> current multipath tools 0.4.7 is incompatible with the dm_multipath module in
> my 2.6.13-15.8 kernel. Also, this would seem to mean that multipathd is also
> incompatible with this kernel.
>
>   
Taken from "The Source", the multipath target syntax is :

/*-----------------------------------------------------------------
 * Constructor/argument parsing:
 * <#multipath feature args> [<arg>]*
 * <#hw_handler args> [hw_handler [<arg>]*]
 * <#priority groups>
 * <initial priority group>
 *     [<selector> <#selector args> [<arg>]*
 *      <#paths> <#per-path selector args>
 *         [<path> [<arg>]* ]+ ]+
 *---------------------------------------------------------------*/

1000 is the default number of IO routed to a path before the driver 
switches to the next path in the same pathgroup. This is the simple way 
to achieve the load-leveling through the "round-robin" selector.

Maybe confusingly, the rr_min_io is the "per-path selector args".
Thus, for a path group in your setup :

<selector> = round-robin
<#selector args> = 0
[<arg>]* = NULL
<#paths> = 1 (in your case)
<#per-path selector args> = 1 (for rr_min_io)
<path> = 8:0 (for one)
[<arg>]* = 1000 (default rr_min_io, proper)

What strikes me in this map "0 443027195 multipath 0 0 2 1 round-robin 1 
1 8:0 1000 round-robin 1 1 8:16 1000" is the lack of <#selector args>.

... but I don't reproduce here : "0 71122560 multipath 1 
queue_if_no_path 0 2 1 round-robin 0 1 1 8:32 100 round-robin 0 1 1 8:80 
100"

> Is anyone aware of a workaround or even a better identification for this
> incompatibility?
>
> Thanks!
>