From owner-freebsd-arch@FreeBSD.ORG Sun Apr 12 18:12:05 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 19E73106566B for ; Sun, 12 Apr 2009 18:12:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id E12AD8FC13 for ; Sun, 12 Apr 2009 18:12:04 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 70DFB46B38; Sun, 12 Apr 2009 14:12:04 -0400 (EDT) Date: Sun, 12 Apr 2009 19:12:04 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Rick Macklem In-Reply-To: Message-ID: References: <49D98461.4000002@elischer.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: 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:12:05 -0000 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