Date: Sun, 12 Apr 2009 14:10:44 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: Doug Rabson <dfr@rabson.org> Cc: Robert Watson <rwatson@freebsd.org>, 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.0904121357270.15456@muncher.cs.uoguelph.ca> In-Reply-To: <C8A9F5A9-9B82-43A5-818A-3771B1B25CC7@rabson.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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 12 Apr 2009, Doug Rabson wrote:
[good stuff snipped]
>
> 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.)
At this point, not starting the callback daemon (nfscbd) implies no
callbacks, but I don't know of an "automagic" way to decide if the
callback path will be stable. NB: A callback path that never works is
just like no callbacks and isn't much of a problem. The problems occur
when the callback path breaks after a while, when the client holds
delegations issued to it by the server.
It might be a good idea to initially ship with callbacks and delegations
disabled, documenting them as "bleeding edge experimental features"?
rick
ps: For now, I think that using rtalloc1() if the callback address
hasn't been set via sysctl, is adequate. However, if changes
to the correct callback address (or knowing that the address
is likely to change) can be detected, that would be nice.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.63.0904121357270.15456>