[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] HSG80, DM, multipath issues

D. North a écrit :
Thus spake Christophe Varoqui (christophe varoqui 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]