Re: [OSR-devel] New Preview RPMs for next Release Candidate of comoonics-bootimage

[Gordan B. <go...@bo...>]

On Fri, 13 Feb 2009 15:08:04 +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).
>
> ;-)

Yeah, it's a bit deja-vu after the reason for the improved probing was that
booting would randomly fail. ;-)

>> 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?

Sounds good. :)

> The about no loading scsidrivers and the like is you cannot selectively 
> trigger udev. Or I didn't find a way.

Fair enough. But if the probing isn't triggered iif the NIC @driver is
specified, then that should avoid the probing anyway. :)

Gordan