From: Mike Eisler (mike@eisler.com)
Date: 10/04/02-03:30:40 PM Z
Message-ID: <3D9DFA70.6050805@eisler.com>
Date: Fri, 04 Oct 2002 13:30:40 -0700
From: Mike Eisler <mike@eisler.com>
Subject: Re: Weak cache consistency in V4?
You, dear co-author, are asking this years after RFC3010 was published? :-)
My re-collection is that this was discussed by the WG
years back, and the conclusion was that we didn't want to
invest specification text and implemenation time on
two forms of caching (wcc and delegations),
Note that wcc for directory modifcations continues to persist
in NFSv4.
-mre
David Robinson wrote:
> In the NFSv3 specification RFC1813 under wcc_data:
>
>> In order to support the weak cache consistency model, the server
>> will need to be able to get the pre-operation attributes of the
>> object, perform the intended modify operation, and then get the
>> post-operation attributes atomically. If there is a window for
>> the object to get modified between the operation and either of
>> the get attributes operations, then the client will not be able
>> to determine whether it was the only entity to modify the
>> object. Some information will have been lost, thus weakening the
>> weak cache consistency guarantees.
>
>
> In NFSv4 we no longer have the concept of wcc_data (or post_op_attr)
> for file modifying operations. The best we can do is to COMPOUND
> the sequence GETATTR, WRITE, GETATTR to simulate the NFSv3 weak
> cache consistency. However, because the suboperations within a
> COMPOUND operation are not atomic, there is no guarentee that either
> the first GETATTR or the second GETATTR reflect the attributes
> before or after the WRITE occured.
>
> In NFSv2, RFC1094, the attrstat returned from a NFSPROC_WRITE also
> guarentees that attributes are atomically acquired after the write.
>
> The net result of this change is that the NFSv4 specification
> provides a weaker mechanism for cache consitency on WRITE
> operations than existed in NFSv2.
>
> Does anyone care?
>
> -David
>
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:24 AM Z CST