Ragnar Kjørstad wrote:

>On Tue, Nov 23, 2004 at 07:46:04PM -0500, Steve Dickson wrote:
>  
>
>>Ragnar Kjørstad wrote:
>>    
>>
>>>1. What happens when you run statd with the "-n" option?
>>> Does this patch override the name the user gave?
>>>
>>>      
>>>
>>hmm.... this is a problem, since the global SM_stat_chge.mon_name
>>that the -n sets is now ignored... I guess I was thinking it would be better
>>for statd to dynamically set the name that sent the notify message.
>>But it would probably be a smart to maintain the same functionality.
>>
>>Question: do people actually run multiple statds using the -n to define
>>the interface they monitor?  That's a scenario  I guess  I didn't think 
>>of but
>>it sound a bit awkward....
>>    
>>
>
>Let me just explain why -n was added in the first place:
>  
>
thanks... that gave me a bit more insight on how the -n is used.... 

>>> This may or may not match the hostname that the server find when
>>> running gethostbyaddr on the interface's IP, so one can easily find
>>> scenarios where this patch will cause statd to stop working.
>>>      
>>>
>>I don't think this is an issue... as long as the hostname and all of its 
>>aliases
>>resolve to the same ip address, things should work since its the ip address
>>the kernel needs to find the lock that has to be reclaimed... 
>>    
>>
>OK, so the client maps the name back to the IP?
>and compares it to gethostbyname() on the hostname that it used to
>mount?
>  
>
close, the client statd does the gethostbyname() and send the ip address
to the kernel via loopback... The kernel then uses that ip address along
with protocol and version to locate the lock.

>Is this in the specification, or only the linux-implementation?
>
>If that's the case, are we allowed to just send the IP instead of the
>name?
>  
>
No, since the spec says a the id_mon needs to be character string....

>  
>
>>Now the 
>>problem
>>arises when the hostname resolves to a different ip address.... 
>>something this patch
>>is trying to address...
>>    
>>
>
>I didn't know the client actually compared IPs - I thought it compared
>the actual names.
>  
>
The kernel searches the list of nlm_hosts look for the correct 
ipaddr,proto,vers
threesome...

>Then I guess it's less of a problem than I thought.
>
>A couple of cases where I think it would fail though:
>- If you have inconsistant name-resolution (/etc/hosts) in
>  your system.
>  
>
Well I don't think it possible to program for a screwy DNS servers,
or should we try.... imho...

>- If you have aliases (eth0, eth0:0) with different IPs but on the
>  same network. The current patch (if I read it correctly) will then
>  use the name from the last alias, which is kind of random.
>  
>
Well it would not be random, it would be the first interface....

>The second case may be very relevant to the HA-problem which "-n" was
>originally added for.
>  
>
Yes... the -n flag wold be the answer here...

> <>
>
>There are two reasons to keep -n:
>
I see your point.... especially since all the HA code is now in
the updated FC3 nfs-utils... Believe me the last thing I want to do
is break  that code....  ;-) so attached is an updated patch that should
not affect the HA code at all....

SteveD.