--On Thursday, July 23, 2009 11:54:01 AM -0400 "Matt W. Benjamin"
<[email protected]> 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
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
