On mer, 2005-04-20 at 22:12 +0200, Lars Marowsky-Bree wrote: > 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 > from libmultipath/discovery.c:devinfo() : if (apply_format(pp->getprio, &buff[0], pp)) { pp->priority = 1; } else if (execute_program(buff, prio, 16)) { condlog(3, "error calling out %s", buff); pp->priority = 1; } else pp->priority = atoi(prio); A failed exec results in a default path weight. This code is common to multipath and multipathd > 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. > Indeed. > 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. > Sure, it was acknowledged and corrected from 0.4.2. Multipathd *never* decides to change a map. All it does is exec multipath, which means two runs of multipath gave 2 differents maps : very bad, but nothing to do with code divergence between daemon and tool. Regards, -- christophe varoqui <christophe.varoqui@xxxxxxx>