From owner-freebsd-fs@FreeBSD.ORG Thu Oct 19 03:10:40 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 B0D8E16A40F for ; Thu, 19 Oct 2006 03:10:40 +0000 (UTC) (envelope-from email2mre-bsdfs@yahoo.com) Received: from web31807.mail.mud.yahoo.com (web31807.mail.mud.yahoo.com [68.142.207.70]) by mx1.FreeBSD.org (Postfix) with SMTP id 4C0DB43D55 for ; Thu, 19 Oct 2006 03:10:40 +0000 (GMT) (envelope-from email2mre-bsdfs@yahoo.com) Received: (qmail 84530 invoked by uid 60001); 19 Oct 2006 03:10:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=4DyWHvWQnJ1w6RB4GLOR/IoFBzySnWuZt0L0DbbkWiKg6cGaRD9JqWMkBgUMm9bUxUHvswFUJvr0zyZRP0vDmAHcdksq/E3fMhjUMWx/cv41iAQ/ISBiXZBTyCjHBIs0rms3CFFvsgMGhqnIJY2Z9SGjqr+DXglLwx1JTuNPja4= ; Message-ID: <20061019031039.84528.qmail@web31807.mail.mud.yahoo.com> Received: from [216.240.30.14] by web31807.mail.mud.yahoo.com via HTTP; Wed, 18 Oct 2006 20:10:39 PDT Date: Wed, 18 Oct 2006 20:10:39 -0700 (PDT) From: Mike Eisler To: fs@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: lost dotdot caching pessimizes nfs especially X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-bsdfs@yahoo.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Oct 2006 03:10:40 -0000 > Date: Mon, 16 Oct 2006 11:32:36 -0400 (EDT) > From: rick@snowhite.cis.uoguelph.ca > To: fs@freebsd.org > Subject: Re: lost dotdot caching pessimizes nfs especially > CC: mohan_srinivasan@yahoo.com > the lines of my experimental NQNFS might have happenned. NFSv4 simply > says that clients that care about cache consistency should use byte While RFC3530does not use the term "close-to-open consistency" (something that I'll address in the NFSv4.1 protocol), it does say: Furthermore, in the absence of open delegation (see the section "Open Delegation") two additional rules apply. Note that these rules are obeyed in practice by many NFS version 2 and version 3 clients. o First, cached data present on a client must be revalidated after doing an OPEN. Revalidating means that the client fetches the change attribute from the server, compares it with the cached change attribute, and if different, declares the cached data (as well as the cached attributes) as invalid. This is to ensure that the data for the OPENed file is still correctly reflected in the client's cache. This validation must be done at least when the client's OPEN operation includes DENY=WRITE or BOTH thus terminating a period in which other clients may have had the opportunity to open the file with WRITE access. Clients may choose to do the revalidation more often (i.e., at OPENs specifying DENY=NONE) to parallel the NFS version 3 protocol's practice for the benefit of users assuming this degree of cache revalidation. Since the change attribute is updated for data and metadata modifications, some client implementors may be tempted to use the time_modify attribute and not change to validate cached data, so that metadata changes do not spuriously invalidate clean data. The implementor is cautioned in this approach. The change attribute is guaranteed to change for each update to the file, whereas time_modify is guaranteed to change only at the granularity of the time_delta attribute. Use by the client's data cache validation logic of time_modify and not change runs the risk of the client incorrectly marking stale data as valid. o Second, modified data must be flushed to the server before closing a file OPENed for write. This is complementary to the first rule. If the data is not flushed at CLOSE, the revalidation done after client OPENs as file is unable to achieve its purpose.