Re: [patch] fix statd -n

[Wendy Cheng <s.wendy.cheng@gmail.com>]

Janne Karhunen wrote:
>
>>  I think you mis-understand our approach. With our patch, you do *not* need
>> to do anything if you have only one single (floating) interface to do nfs
>> export (and you can have the machine configured to use other hostname). The
>> statd's "my_name" is correctly filled (from kernel by our patch) - it is no
>> longer bound to 127.0.0.1.
>>     
>
> What happens when it fails over to node that has
> different name?  Mon_name in NOTIFY changes
> while address it's coming from does not. Which
> one should client believe - the address or the
> name?
>
> But OK, I probably need to dig out the patch to
> have a look.
>   
In the middle of re-doing our old patch (it should be very small this 
time, with Frank's patch already in mainline and Chuck taking over IPV6 
issues) so the logic can be clear. I also have a feel that you never 
look into "sm-notify" ? Get nfs-util git tree source and take a look at 
the "README" file in the top directory. Either Neil Brown or Steve 
Dickson had added a nice "DAEMON STARTUP ORDER" there. Basically the 
whole issue is a two-steps thing:

1. statd is the process responsible for recording client address into 
the nsm directory
2. sm-notify is the process responsible for notifying clients about 
server reboot activities.

The "sm-notify" design allows the flexibility of notifying clients with 
different cluster configurations, including yours. I think you already 
know this stuff very well... just do a "man sm-notify" ... it should 
clear up your confusions.

-- Wendy