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

[Jeffrey Altman]

Matt W. Benjamin wrote:
>
> ----- "Jeffrey Hutzelman" <jhutz@cmu.edu> wrote:
>   
>>
>> I'm not sure what you mean here.  A FID+DV names a string of bits,
>> period.
>
> It's in no way in dispute that, on the wire, "A FID+DV names a string of bits."  In order to analyze cache coherence, though (in a system which considers caching), it is necessary to describe and reason about the views of a file clients have cached.  In a cache, necessarily, it is not sufficient to consider the coherence only protocol messages--what we're reasoning about, in addition, is a distributed system with state.  
>
> Moreover, I think it's clear that in a cache, we're concerned about not only the coherence of the distributed images of the cache, but, also, the relationship of data that is cached with computations which may be in progress on cached instances of the data.  It is in this sense that I used the term "useful" (or not useful).  As Tom pointed out in side conversation, this is not a gray area in computing science.   "Basically [what] you're asserting is the classical SMP mutual exclusion problem -- just having cache coherence isn't enough to guarantee deterministic outcome of a parallel application [sic, i.e., computation] without the use of synchronization primitives" (tkeiser).
The contents of an object after modification is no longer represented by
FID+DV.   It is now FID+DV-prime which represents a value that is not
known to any other client or server.  It is not part of a transaction. 
It can be done or undone.  Until FID+DV-prime is stored to the file
server, from the perspective of the rest of the world it does not
exist.   The transactions that matter for the purpose of analysis are
the atomic operations that are performed with the file server and those
are the ones that are represented on the wire.

If an application wishes to ensure that the data written locally is
synchronized with the rest of the world prior to the StoreData RPC file
locking must be used.  

Jeffrey Altman