On 2005-04-20T16:20:23, christophe varoqui <christophe.varoqui@xxxxxxx> wrote:
> I guess I'll setup the OSDL environment now, for testing and debugging.
> Hope to be able to diagnose in a few hours.
Something else is strange.
This is what /sbin/multipath creates:
0 267249280 multipath 0 1 emc 2 1 round-robin 0 2 1 66:208 1000 8:240 1000 round-robin 0 2 1 65:224 1000 8:0 1000
action preset to 0
action set to 4
create: 3600601607cf30e00164589a37a31d911
[size=127 GB][features="0"][hwhandler="1 emc"]
\_ round-robin 0 [first]
\_ 1:0:1:0 sdat 66:208 [ready ]
\_ 0:0:1:0 sdp 8:240 [ready ]
\_ round-robin 0
\_ 1:0:0:0 sdae 65:224 [ready ]
\_ 0:0:0:0 sda 8:0 [ready ]
multipathd however:
...
Apr 20 22:09:11 chip multipathd: getprio = /sbin/pp_emc /dev/%n (controler setting)
Apr 20 22:09:11 chip multipathd: error calling out /sbin/pp_emc /dev/sdp
Resulting in a flat map:
3600601607cf30e0070af8bb37a31d911
[size=133 GB][features="0"][hwhandler="1 emc"]
\_ round-robin 0 [active][first]
\_ 0:0:1:12 sdab 65:176 [ready ][active]
\_ 1:0:0:12 sdaq 66:160 [ready ][active]
\_ 1:0:1:12 sdbf 67:144 [ready ][active]
\_ 0:0:0:12 sdm 8:192 [ready ][active]
Which is broken and actually causes the system to misbehave quite
spectacularly.
What is multipathd doing differently from multipath? The two parts being
distinct in behaviour is really one of the worst design decisions in the
entire setup, in my not so humble opinion.
Second, if a callout _fails_, it ought to refuse to create the map IMHO,
rather than risk creating a broken one.
Sincerely,
Lars Marowsky-Brée <lmb@xxxxxxx>
--
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business
