From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: Why must NFS access metadata in synchronous mode? Date: Fri, 02 Jun 2006 00:06:53 -0400 Message-ID: <1149221213.17428.21.camel@lade.trondhjem.org> References: <4ae3c140605312104m441ca006j784a93354456faf8@mail.gmail.com> <1149141341.13298.21.camel@lade.trondhjem.org> <4ae3c140606010927t308e7d6ag5a9fc112c859aa45@mail.gmail.com> <1149182779.3549.25.camel@lade.trondhjem.org> <3B8B2FFD-A2CD-4657-9AB2-564CB64D61CF@stanford.edu> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Xin Zhao , linux-fsdevel@vger.kernel.org Return-path: Received: from pat.uio.no ([129.240.10.4]:57522 "EHLO pat.uio.no") by vger.kernel.org with ESMTP id S1751301AbWFBEHO (ORCPT ); Fri, 2 Jun 2006 00:07:14 -0400 To: Can Sar In-Reply-To: <3B8B2FFD-A2CD-4657-9AB2-564CB64D61CF@stanford.edu> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, 2006-06-01 at 20:42 -0700, Can Sar wrote: > On Jun 1, 2006, at 10:26 AM, Trond Myklebust wrote: > > > > ...and how does that help the user that has been told the operation > > succeeded? > > It wouldn't. For externally visible operations the kernel just waits > until it actually has the right answer. > Contributions from that paper would definitely speed up NFS on Linux > but they require extensive work, which is one of the reasons no one > has actually implemented a production level version of that work yet > (researchers generally move on to new papers instead). Performance needs to be weighted against application expectations (i.e. POSIX correctness). If the application is told that an operation has succeeded, then you had better make damned sure that the operation _will_ succeed (and within finite time, please!). As I said, we are working within the IETF on a model for asynchronous operations, but as Andreas Dilger suggested, this does require a stateful model in which the client can reliably conclude whether or not an operation will succeed in the future. Such a model is understandably complex to design, and so we're introducing the framework in a step-by-step manner: NFSv4.1 will include directory read delegations (which allow you to cache directory operations that do not modify the directory until a conflict occurs). I hope we will get round to completing a model for write delegations in NFSv4.2. Trond