Bug#580972: multipath-tools: unnecessary call to multipath in /etc/udev/rules.d/z60_multipath.rules

[Faidon Liambotis]

On Mon, May 10, 2010 at 06:08:56PM +0200, Guido Günther wrote:
> Hi Apollon,
> On Mon, May 10, 2010 at 12:57:07PM +0300, Apollon Oikonomopoulos wrote:
> > Multipathd itself has uevent support, which is what the first rule is used for.
> > However, the second rule is redundant and useful only in the case of block
> > devices showing up during boot, between /etc/init.d/multipath-tools-boot and
> > /etc/init.d/multipath-tools. Furthermore, it causes major system load whenever
> > a bulk of new LUNs are added to a running system. In our case, adding 10 LUNs
> > with 8 paths each causes the system load to rocket to 70-80 for 25s, while 80
> > multipath processes are racing to coallesce the multipaths. Disabling the
> > second rule causes the whole process to finish in less than 2 seconds while
> > multipathd itself handles the uevents generated by the kernel.
> > 
> > It should be noted that upstream do not include the second rule in their sample
> > rulefile[1].
> > 
> > Thus, the second rule should be removed or at least check whether multipathd is
> > running before executing /sbin/multipath.
> This is also necessary for the initramfs since we don't run multipathd
> there. Testing if multipathd is runnning looks like a good option
> though. It'd be even nicer if we could only run that rule if the former
> one fails.

Ping? From experience, this is quite a serious issue on large multipath
setups, the problem being in a Debian-specific modification that can
easily be fixed.

Regards,
Faidon