Date: Wed, 18 Oct 2006 20:10:39 -0700 (PDT) From: Mike Eisler <email2mre-bsdfs@yahoo.com> To: fs@freebsd.org Subject: Re: lost dotdot caching pessimizes nfs especially Message-ID: <20061019031039.84528.qmail@web31807.mail.mud.yahoo.com>
next in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061019031039.84528.qmail>