From owner-freebsd-fs@FreeBSD.ORG Sun Oct 15 21:35:14 2006 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36B5C16A403 for ; Sun, 15 Oct 2006 21:35:14 +0000 (UTC) (envelope-from mohan_srinivasan@yahoo.com) Received: from web30813.mail.mud.yahoo.com (web30813.mail.mud.yahoo.com [68.142.201.139]) by mx1.FreeBSD.org (Postfix) with SMTP id DEEB143D4C for ; Sun, 15 Oct 2006 21:35:09 +0000 (GMT) (envelope-from mohan_srinivasan@yahoo.com) Received: (qmail 60931 invoked by uid 60001); 15 Oct 2006 21:35:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Esd+M0gwv7AP+XDiSdAiLx/QKt9R1xptkpnXb4+zmqvDVZBMp8lUgpGqt4z2qitkpSA9HiQTUvh8eCW6GqEZ7KLRgvrH5HcXNPVoFyUjDfa42LjgtdZufEfD7Zt5dm8wYQxJfngdANynQ3MeSupw6FPPx+/vZH21dZ/VWOA3Jss= ; Message-ID: <20061015213509.60929.qmail@web30813.mail.mud.yahoo.com> Received: from [71.139.1.197] by web30813.mail.mud.yahoo.com via HTTP; Sun, 15 Oct 2006 14:35:09 PDT Date: Sun, 15 Oct 2006 14:35:09 -0700 (PDT) From: Mohan Srinivasan To: rick@snowhite.cis.uoguelph.ca, fs@freebsd.org In-Reply-To: <200610152126.RAA49191@snowhite.cis.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: mohan_srinivasan@yahoo.com Subject: Re: lost dotdot caching pessimizes nfs especially X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Oct 2006 21:35:14 -0000 SunOS and Solaris have provided close-to-open consistency for a very long time (for at least 15 years now). Not having the NFS client enforce close-to-open consistency will break a heck of a lot of applications. Since the other NFS clients (that matter) Solaris and Linux support it, I would argue that not supporting cto consistency is not really an option. We can however provide a mount option "nocto" (like those clients do) that overrides the default for specific cases (read only mounts, single client mounts etc). mohan --- rick@snowhite.cis.uoguelph.ca wrote: > > The clearing of the attrcache on nfs_open() is a requirement for close-to-open > > consistency, and this change fixed bugs that we saw internally relating to > > close-to-open consistency. > > I thought I'd just throw out some comments w.r.t. close-to-open consistency. > The concept comes from the Andrew File System (before Transarc's AFS), where > the client read the entire file upon Open and wrote the entire file to the > server upon Close, if it was modified. Therefore, other clients that opened > the file after the Close were guaranteed to see the changes. > > To the best of my knowledge, no NFS RFC has even required this behaviour. > It became common practice to flush writes to a server upon Close, so that > errors like ENOSPC could be returned by close(2) and a process could be > confident that the file was successfully saved if it didn't get an error > return from any write(2) syscall nor the subsequent close(2). > > As a side effect of the above behaviour (not required by RFC, but common > practice), NFS clients provided "approximate close-to-open consistency". > The "approximate" came from the fact that another client wouldn't notice > that the file had been modified until its attribute cache had timed out, > a few seconds after the writing client had flushed its writes upon close. > > Somewhere along the way, some people seem to have decided that > close-to-open consistency is required of NFS clients. I think the Linux crowd > is in that camp? > > Since NFS doesn't have a cache coherency protocol (even for NFSv4, although > the caching rules are somewhat more explicit in RFC3530), it is always > a performance<->consistency tradeoff. > > So, I guess you guys will have to decide, rick > ps: I do believe software that expects strict close-to-open consistency > over NFS is not correct, because that is not a requirement of the RFCs. >