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