From owner-freebsd-arch@FreeBSD.ORG Sun Apr 12 18:04:24 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA45410656EB; Sun, 12 Apr 2009 18:04:24 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from gigi.cs.uoguelph.ca (gigi.cs.uoguelph.ca [131.104.94.210]) by mx1.freebsd.org (Postfix) with ESMTP id A02498FC16; Sun, 12 Apr 2009 18:04:24 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by gigi.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id n3CI4JLl011723; Sun, 12 Apr 2009 14:04:19 -0400 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n3CIAiB17850; Sun, 12 Apr 2009 14:10:44 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Sun, 12 Apr 2009 14:10:44 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Doug Rabson In-Reply-To: Message-ID: References: <49D98461.4000002@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.63 on 131.104.94.210 Cc: Robert Watson , Julian Elischer , freebsd-arch@freebsd.org Subject: Re: getting a callback ip address for nfsv4 client X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Apr 2009 18:04:26 -0000 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.