From owner-freebsd-hackers@FreeBSD.ORG Tue May 12 20:56:13 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0ED0106564A for ; Tue, 12 May 2009 20:56:13 +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 67A278FC15 for ; Tue, 12 May 2009 20:56:13 +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 9B39A46B65; Tue, 12 May 2009 16:56:12 -0400 (EDT) Date: Tue, 12 May 2009 21:56:12 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Konrad Heuer In-Reply-To: Message-ID: References: <20090508101555.J47014@gwdu60.gwdg.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: How to invalidate NFS read cache? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2009 20:56:13 -0000 On Tue, 12 May 2009, Robert Watson wrote: > Normally, NFS clients implement open-to-close consistency, which dictates > that when a close() occurs on client A, all pending writes on the file > should be issued to the server before close() returns, so that a signal to > client B to open() the file can validate its cache before open() returns. This should, of course, read "close-to-open consistency" -- I plead jetlag after an overnight flight back form Boston to the UK :-) Robert N M Watson Computer Laboratory University of Cambridge > > This raises the following question: is client A closing the file, and is > client B then opening it? > > If not: relying on writes being visible on the client B before the close() on > A and a fresh open() on B is not guaranteed to work, although we can discuss > ways to improve behavior with respect to expectation. Try modifying your > application and see if it gets the desired behavior, and then we can discuss > ways to improve what you're seeing. > > If you are: this is probably a bug in our caching and or issuing of NFS RPCs. > We cache both attribute and access data -- perhaps there is an open() path > where we issue neither RPC? In the case of open, we likely should test for a > valid access cache entry, and if there is one, issue an attribute read, and > otherwise just issue an access check which will piggyback fresh attribute > data on the reply. Perhaps there is a bug here somewhere. > > A few other misc questions: > > - Could you confirm you're using NFSv3 on all clients. Are there any special > mount options in use? > - What version of FreeBSD are you running with? > > In FreeBSD 8.x, we now have DTrace probes for all of the above events -- > VOPs, attribute cache hit/miss/load/flush, access cache hit/miss/load/flush, > RPCs, etc, which we can use to debug the problem. I haven't yet MFC'd these > to 7.x, but if you're able to run a very fresh 7-STABLE, I can probably > produce a patch to add it for you in a few days. > > Robert N M Watson > Computer Laboratory > University of Cambridge >