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

[Olaf Kirch <okir@lst.de>]

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

Olaf
-- 
Olaf Kirch  |  --- o --- Nous sommes du soleil we love when we play
okir at lst.de |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax