[Cluster-devel] Re: [NFS] [PATCH 3/4 Revised] NLM - kernel lockd-statd changes

[Wendy Cheng <wcheng@redhat.com>]

Olaf Kirch wrote:
> On Thursday 05 April 2007 23:52, Wendy Cheng wrote:
>   
>> The changes record the ip interface that accepts the lock requests and 
>> passes the correct "my_name" (in standard IPV4 dot notation) to user 
>> mode statd (instead of system_utsname.nodename). This enables rpc.statd 
>> to add the correct taken-over IPv4 address into the 3rd parameter of 
>> ha_callout program. Current nfs-utils always resets "my_name" into 
>> loopback address (127.0.0.1), regardless the statement made in rpc.statd 
>> man page. Check out "man rpc.statd" and "man sm-notify" for details.
>>     
>
> I don't think this is the right approach. For one, there's not enough
> room in the SM_MON request to accomodate an additional IPv6
> address, so you would have to come up with something entirely
> different for IPv6 anyway. 

The original plan was to pass fsid instead of floating ip but it 
required some major restructures on host lookup and file lookup (in 
nlmsvc_retrieve_args). I have been hoping by the time IPV6 is really 
required, NFS V4 would be mature enough to get deployed (so this would 
be a non-issue anyway).

If people doesn't mind to restructure the sequence of host and file 
lookup, passing fsid can be one of the strong candidates to get this right.

> But more importantly, I think we should
> move away from associating all sorts of network level addresses
> with lockd state - addresses are just smoke and mirrors. Despite
> all of NLM/NSMs shortcomings, there's a vehicle to convey identity,
> and that's mon_name. IMHO the focus should be on making it work
> properly if it doesn't do what you do.
>
> But - why do you need to record the address on which the request was
> received. at all? Don't you know beforehand on which IP addresses you
> will be servicing NFS requests, and which will need to be migrated?
>
> Side note: should we think about replacing SM_MON with some new
> design altogether (think netlink)?
>
>   
Totally agree ! More on this later when I'm back to office.

-- Wendy