Re: [PATCH] mount.nfs: restore admin-specified clientaddr option

[Chuck Lever <chuck.lever@oracle.com>]

[-- Attachment #1: Type: text/plain, Size: 1564 bytes --]

Trond Myklebust wrote:
> 'clientaddr' was set up because there is no way for the kernel (or an
> automated userland mount program) to determine exactly which IP address
> the server should be using for callbacks in the case where there are
> more than 1 options.
> That all depends on the local network topology, and routing policies,
> which may not be visible to the client.

The patch corrects a mistaken assumption I made while working on the 
text-based mount implementation.  The broken behavior is only a week or 
so old, doesn't affect legacy nfs4_mount_data style mounts, and was 
never part of an nfs-utils release.

It would be wonderful if we had some of these requirements written down 
somewhere, so we wouldn't be dependent on individuals who are 
unavailable at times when we need some historical perspective.  I've 
started doing this here:

http://wiki.linux-nfs.org/wiki/index.php/NewMountDesignSpec

You have to admit that existing mount option documentation is pretty 
scant on history and rationale.  Look at what nfs(5) says about 
clientaddr= :

> clientaddr=n   On a multi-homed client, this causes the client to use a
>                specific callback address when communicating with an NFS
>                version 4 server.  This option is currently ignored.

"This option is currently ignored."  Ummm....

And Neil just fixed the "multi-homed" part of mount's automated 
clientaddr generation.

And nfs(5) doesn't say Jack about NAT routers or network topology or 
routing policies.

I will send in a patch that also corrects nfs(5).

[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 290 bytes --]

begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
url:http://oss.oracle.com/~cel
version:2.1
end:vcard


[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs