Date: Sun, 12 Apr 2009 15:50:50 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Robert Watson <rwatson@FreeBSD.org> Cc: Julian Elischer <julian@elischer.org>, freebsd-arch@FreeBSD.org Subject: Re: getting a callback ip address for nfsv4 client Message-ID: <Pine.GSO.4.63.0904121515220.27116@muncher.cs.uoguelph.ca> In-Reply-To: <alpine.BSF.2.00.0904121906270.19879@fledge.watson.org> 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> <alpine.BSF.2.00.0904121906270.19879@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 12 Apr 2009, Robert Watson wrote: > > 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?) > Yes, what I am thinking of (I've coded parts of it, but always get distracted before I get it working:-) is whole file caching on local disk for delegated files, up to a certain size. And yes, if the delegation info is stored on stable storage, such as local disk, a client can recover it after a reboot. (Since no client currently does this, that part of current servers isn't heavily tested, so doing so could get "interesting":-) So, yes, I'd like to see delegations working, too. > 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. > The first scenario is problematic for nfsv4. If a client doesn't do a lease renewal within the server's chosen lease duration, the server has the right to throw away state, including locks and delegations. Most servers choose a lease duration of 1-2 minutes these days, so it needs to be "fast commute":-) Actually, my server chooses to be lenient and only expires state when it has to, due to a conflicting request or resource exhaustion and not just upon lease expiration, so you might be ok with a FreeBSD server, but not a Linux one (oh wait, you folks might actually consider that a feature:-). The second brings up the question of NAT, which I know diddly about. (I vaguely thought that neither rtalloc() nor getsockaddr() would work, since they would return 192.168.x.x and you really need the address assigned by the isp?) Can someone help w.r.t. what address to use when behind a NAT? Doug, maybe a client could optionally set an "upcall function" that would be called with the local ip address upon each reconnect to a server? (Then the nfsv4 client could check to see if the address had changed and do a fresh SetClientID/SetClientIDConfirm to change it, if it has?) > (Obviously, none of this really matters until delegations work...) Well, depends upon your definition of "work". At this point, they seem to function fine so long as the callback path is working and my client does do local opens and locking when it has a delegation. It doesn't yet do any clever caching and the FreeBSD kernel needs something (I am planning on posting a first stab at this in a few days) done before local VOP_RENAME() and VOP_ADVLOCK() calls to ensure consistency with locallly done ops. be added for correctness. rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.63.0904121515220.27116>