From owner-freebsd-fs@FreeBSD.ORG Sun Oct 15 21:26:22 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 F20A216A407 for ; Sun, 15 Oct 2006 21:26:22 +0000 (UTC) (envelope-from rick@snowhite.cis.uoguelph.ca) Received: from dargo.cs.uoguelph.ca (dargo.cs.uoguelph.ca [131.104.94.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD14C43D73 for ; Sun, 15 Oct 2006 21:26:21 +0000 (GMT) (envelope-from rick@snowhite.cis.uoguelph.ca) Received: from snowhite.cis.uoguelph.ca (snowhite.cis.uoguelph.ca [131.104.48.1]) by dargo.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id k9FLQFnp020996; Sun, 15 Oct 2006 17:26:15 -0400 Received: (from rick@localhost) by snowhite.cis.uoguelph.ca (8.9.3/8.9.3) id RAA49191; Sun, 15 Oct 2006 17:26:20 -0400 (EDT) Date: Sun, 15 Oct 2006 17:26:20 -0400 (EDT) From: rick@snowhite.cis.uoguelph.ca Message-Id: <200610152126.RAA49191@snowhite.cis.uoguelph.ca> To: fs@freebsd.org X-Scanned-By: MIMEDefang 2.52 on 131.104.94.197 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:26:23 -0000 > 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.