Or Gerlitz [off-list ref] wrote:

On 9/27/06, Jay Vosburgh [off-list ref] wrote:

quoted

Or Gerlitz [off-list ref] wrote:

[...]

quoted

        You almost want to have some kind of call to induce a reload
from scratch of the multicast filter settings (along with whatever else
might be necessary to alter the hardware type on the fly), to be called
by bonding at the time the first slave is added (since slave adds happen
in user context, and can therefore hold rtnl as required by most of the
multicast address handling code).  That seems less hassle than having to
specify the hardware type and address length at module load time.

I agree that it would be better to avoid doing it this way.

	Actually, it would be ideal to do it this way in all cases, as
the change of hardware type is the biggest hurdle to cross-hardware
bonding instances.  The current infrastructure simply won't allow it,
though, since bonding failover events usually occur in a timer context
(if memory serves, timers run in softirq and can't acquire rtnl).

[...]

quoted

        Other random thoughts on how to resolve this include modifying
bonding to accept slaves when the master is down (which would also
require changes to the initscripts that normally configure bonding), so
that the initial setting of the, e.g., 224.0.0.1 multicast hardware
address happens to the already-changed hardware type.

OK, this is a direction i would like to check. Can be nice if you
provide me with a 1-2 liner of directions on what need to be changed
to enable bonding to accept slaves when it down.

	I don't think right offhand this would be a particularly
difficult change; the "up" operation for bonding mostly just starts up
various timers.  A few minutes poking around doesn't reveal anything
obvious that would hinder enslaving with the master down.  You'll have
to change ifenslave and the sysfs code to allow enslaves with the master
down; that might be all that's needed for bonding itself.  Changing
/sbin/ifup and friends is a separate problem.

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com