From: Marc G. <gr...@at...> - 2009-02-13 14:08:11
|
On Friday 13 February 2009 12:33:06 Gordan Bobic wrote: > On Thu, 12 Feb 2009 10:13:38 +0100, Marc Grimme <gr...@at...> wrote: > > But how about your hw-detection does it work now stable? Cause my cluster > > that had the problems is running just fine. > > I've not tested the new versions on the cluster that was having problems, > but I have tested it on another cluster, and although it does seem to work > fine in general, the new probing approach managed to crash the machine > once. I'll test it some more since I've only seen that happen once (after a > reboot it came up OK). ;-) > > A few observations - the first probing pass doesn't clean up and unload > modules properly. The dependencies among the drivers don't get resolved, > so, for example, scsi disk drivers don't get unloaded properly because they > have dependencies, which causes errors to get reported back. > > The other immediate observation is that the probing is very slow compared > to the old image. It takes 2-3 times longer to get to the final init. The > fact that I have a lot of SATA ports (10) in that system probably doesn't > help. > > So, what would be really nice is a way to only do probing if configuration > information isn't available (e.g. modprobe.conf^H^H^H^H^H^H^H^H^H^H^H^H^H^H > driver= parameter in cluster.conf ;-)) - and by this I am referring to disk > controller drivers in addition to the NIC drivers. Multi-pass probing is > all well and good for a default approach, but it would be really nice to be > able to skip it for performance reasons with the configuration explicitly > specified. Hm. I see your point. What about this if and only if the @driver is specified for every node in the cluster.conf we are using these drivers to detect the MAC Addresses and skip everything else? The about no loading scsidrivers and the like is you cannot selectively trigger udev. Or I didn't find a way. -- Gruss / Regards, Marc Grimme http://www.atix.de/ http://www.open-sharedroot.org/ |