I seem to have omitted a couple of bits. My paragraph 2, sentence 2 is intended to read (for good or ill):
"I think that it is relevant to both discussions that, even two clients simultaneously mutating a file (presume that one or both has not yet stored), produce states of the distributed system (the set of all views of the file) which violate the single-representation assertion." ----- "Matt W. Benjamin" <[email protected]> wrote: > 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 -- 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
