[AFS3-std] Re: [OpenAFS-devel] convergence of RxOSD, Extended Call Backs, Byte Range Locking, etc.

[Jeffrey Hutzelman]

--On Thursday, July 23, 2009 11:54:01 AM -0400 "Matt W. Benjamin" 
<matt@linuxbox.com> wrote:

>> > 4) lack of write-atomicity entirely changes the meaning of DV in the
>> protocol
>>
>> If you want read and write from different clients at the same time in
>> a
>> way that can produce inconsistencies you should use advisory locking.
>> Also without OSD an intermediate StoreData because of the cache
>> becoming
>> full may leed to an intermediate data version which from the
>> application's point of view is inconsistent.
>
> I think I more agree with the "then use locking" response than with the
> objection, but not unequivocally.  Tom's use of language here ("entirely
> changes the meaning") appears to me to be an attempt to nail down a
> meaning for DV that it never had--but I say this as someone who would
> like to incorporate stronger, negotiated semantics in the AFS protocol.

It has always been the case that a particular DV refers to a specific 
version of the content of a vnode.  Any operation which changes the data of 
a vnode also changes its DV at the same time (atomically), period.  It is 
never possible for two different sets of bits to be represented by the same 
DV(*).  This is very important, because it means that clients know that if 
the fileserver says that a vnode has a particular DV, and the client has 
data in its cache labelled with that DV, then the data is correct.  Note 
that while the fileserver can inform a client that metadata in its cache is 
stale and must be refetched, _there is no way for the fileserver to 
invalidate cached data_.  Existing clients depend on this property, and 
have done so since the beginning; it cannot be ignored.


-- Jeff