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

[Matt W. Benjamin]

Hi Jeff,

1. The DV concept carries the assertion that any representation of a (range of a) file at a DV is equivalent to any other representation.  I seem to be the weakening this assertion in my statement, sorry. 

We've discussed related concepts, in the context of async delivery of extended callbacks, a number of times before.  I think that it is relevant to both discussions that, even two clients simultaneously mutating a file (one or both has not yet stored), states of the distributed system (set of all views of the file) that violates the assertion.  I think it is critical to think through the implications of this.  I think that asserting that single store operations be synchronous across the distributed views if the caches do not take reservations, as I believe they do in DFS, is not a useful consistency guarantee.  And, I think it's the case that in the common case for DFS, the reservation is probably useless, because it's not coordinated with the applications doing the I/Os.

2. I do not follow your distinction between data and metadata, with respect to what clients now do and what xcb clients are specified to do on receipt of a StoreData extended callback notification (data changed in a range).  Could you please clarify?

Matt

----- "Jeffrey Hutzelman" <jhutz@cmu.edu> wrote:

> --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.

I don't understand how to parse the assertion that the fileserver cannot invalidate cached data.

reasonable statement.

> 
> 
> -- Jeff
> 
> _______________________________________________
> AFS3-standardization mailing list
> AFS3-standardization@openafs.org
> http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization

-- 

Matt Benjamin

The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309