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