Re: [PATCH net 3/3] bonding:force to use primary slave

[Jay Vosburgh <fubar@us.ibm.com>]

Nicolas de Pesloüan 	<nicolas.2p.debian@gmail.com> wrote:

>Le 11/06/2012 11:00, Weiping Pan a écrit :
>> When we set primary slave with module parameters, bond will always use this
>> primary slave as active slave.
>>
>> But when we modify primary slave via sysfs, it will call
>> bond_should_change_active() and take into account primary_reselect.
>>
>> And I think we should use the new primary slave as the new active slave
>> regardless of the value of primary_reselect.
>> Thus the behavior is the same with module parameters and meets the
>> administrator's expectation.
>>
>> Signed-off-by: Weiping Pan<wpan@redhat.com>
>> ---
>>   drivers/net/bonding/bond_sysfs.c |    1 +
>>   1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
>> index 1b0f3cd..7256ae4 100644
>> --- a/drivers/net/bonding/bond_sysfs.c
>> +++ b/drivers/net/bonding/bond_sysfs.c
>> @@ -1077,6 +1077,7 @@ static ssize_t bonding_store_primary(struct device *d,
>>   				bond->dev->name, slave->dev->name);
>>   			bond->primary_slave = slave;
>>   			strcpy(bond->params.primary, slave->dev->name);
>> +			bond->force_primary = true;
>>   			bond_select_active_slave(bond);
>>   			goto out;
>>   		}
>
>Not sure this is the right behavior. One may want to change the primary
>without causing a switch to this primary if another slave is already
>active, and setup primary_reselect to failure or better for that
>reason. The administrator still have the option to write into
>active_slave, to force the new active slave after changing the primary.
>
>Arguably, this should be documented.

	I suspect it is obeying the documented behavior, at least for
the behaviors that are documented.

	The documentation already says that "When initially enslaved,
the primary slave is always made the active slave."  That's probably
what covers the "module param" case, because the options are all set
prior to any slaves being added, so when the primary slave is later
enslaved, it is made the active slave immediately.

	Now, the documentation for the primary option itself also says:

	"The specified device will always be the active slave while it
	is available.  Only when the primary is off-line will alternate
	devices be used."

	Which is the old behavior, prior to primary_reselect being added
(although it is still the default behavior).  This should probably
change to reflect the actual behavior, i.e., that changing the primary
option in real time results in a reselection of the primary according to
the policy specified by primary_reselect.

	-J

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