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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
