[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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 (, 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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]