[Cluster-devel] Re: [NFS] [PATCH 3/4 Revised] NLM - kernel lockd-statd changes
Wendy Cheng
wcheng at redhat.com
Tue Apr 10 15:00:06 UTC 2007
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
More information about the Cluster-devel
mailing list