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

[Guido Günther]

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.

> One final note: multipathd uevent handling is broken with kernel 2.6.32, fixed
> in a backwards compatible way upstream with commit
> 7fa7affc3d23dd9dc906804d22a61144bca9f9b9 (already present in squeeze/sid).
> I know this is more of a wishlist item, but please backport the fix if possible
> to make lenny's multipathd usable with newer kernels.
That's a different bug only affecting Lenny. Since we might end up
fixing #580956. However having this mixed up in another report almost
makes sure it gets lost ;)
Cheers,
 -- Guido