getting a callback ip address for nfsv4 client

[Robert Watson]

On Sun, 12 Apr 2009, Rick Macklem wrote:

>> I'm less sure about how to handle address changes, if at all. I don't think 
>> the NFSv4 spec says anything on the matter. In NFSv4.1, callbacks are 
>> multiplexed onto the same connection as for regular forward RPCs so the 
>> problem will eventually go away.
>
> Address changes are problematic. If the nfsv4.0 client knows about an 
> address change, it can do a fresh SetClientID/SetClientIDConfirm to tell the 
> server about the new address.
>
> However, I think the safest thing for the client to do if a callback path 
> isn't going to be stable, is to disable callbacks. (This just implies that 
> the server won't choose to issue delegations and everything still works. To 
> be honest, at this point, there isn't even much of a performance gain from 
> delegations, although I am hoping to figure out how to use them to improve 
> client side caching over the next year or so.)

If we want to consider doing client-side disk caching, such as paging out NFS 
buffer cache to local swap, having delegations so we can invalidate the cache 
is fairly important.  It becomes even more important if we want to do 
persistent client-side disk caching across reboots, as found in systems like 
AFS (does the NFSv4 design allow for this, or are client reboots still 
necessarily considered terminal for all caching?)

The kind of scenario I have in mind isn't my IP address changing every 30 
seconds, in which case NFS will be fairly useless anyway.  It's more the "My 
IP changes twice a day when I suspend my notebook and commute to or from my 
office", or alternatively "My desktop is behind a NAT at home, and the ISP 
reboots my DSL modem once a month, which changes my ISP".  In both of those 
scenarios, quickly noticing and re-establishing the callback path so that more 
effective caching can be used might make a significant difference.

(Obviously, none of this really matters until delegations work...)

Robert N M Watson
Computer Laboratory
University of Cambridge