Date: Sun, 12 Apr 2009 19:12:04 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: Julian Elischer <julian@elischer.org>, freebsd-arch@freebsd.org Subject: Re: getting a callback ip address for nfsv4 client Message-ID: <alpine.BSF.2.00.0904121906270.19879@fledge.watson.org> In-Reply-To: <Pine.GSO.4.63.0904121357270.15456@muncher.cs.uoguelph.ca> References: <Pine.GSO.4.63.0903301733120.17182@muncher.cs.uoguelph.ca> <alpine.BSF.2.00.0904051826550.12639@fledge.watson.org> <49D98461.4000002@elischer.org> <alpine.BSF.2.00.0904061143190.34905@fledge.watson.org> <Pine.GSO.4.63.0904061132190.19343@muncher.cs.uoguelph.ca> <BE45DEE0-8D98-4B32-B48A-4D86834DD6E2@rabson.org> <alpine.BSF.2.00.0904121323220.19879@fledge.watson.org> <C8A9F5A9-9B82-43A5-818A-3771B1B25CC7@rabson.org> <Pine.GSO.4.63.0904121357270.15456@muncher.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0904121906270.19879>