[AFS3-std] Re: [OpenAFS-devel] convergence of RxOSD, Extended
Call Backs, Byte Range Locking, etc.
Matt W. Benjamin
matt@linuxbox.com
Thu, 23 Jul 2009 14:05:23 -0400 (EDT)
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" <matt@linuxbox.com> 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" <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
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> 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