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" <[email protected]> wrote: > --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. I don't understand how to parse the assertion that the fileserver cannot invalidate cached data. reasonable statement. > > > -- Jeff > > _______________________________________________ > AFS3-standardization mailing list > [email protected] > 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 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
