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

Jeffrey Altman jaltman@secure-endpoints.com
Mon, 27 Jul 2009 11:59:27 -0400


Hartmut Reuter wrote:

> Jeffrey:
> Is that the kind of specification you are looking for? Or what else?

I would like a specification of the entire protocol such that it is
sufficient for me to be able to implement RXOSD support based solely on
the specification.  The specification must include not only the protocol
messages but also a description of the required semantics.  Only with
such a specification will it be possible for independent developers to
implement RXOSD.  More importantly, only with such a specification is it
possible for analysis to be done of the protocol to identify areas where
it alters the existing AFS protocol semantics, or conflicts with other
work that is in progress.

The concerns that Tom Keiser raised are serious.  One of them will be
addressed via the use of Start/Extend/End messages for Fetch and Store
operations.  However, there are still open questions.  What is the
behavior when a client dies after sending a Start Store?  Is there a
rollback mechanism that the file server must use to restore the
pre-existing data version?  Does the file server assume that the data
was written and increment the data version?  These are decisions that
will need to be made and I'm sure that there is not going to be
consensus on what the answer should be.

Also, any discussion regarding revisions to the afs3 protocol must take
place on afs3-standardization@openafs.org.  The
openafs-devel@openafs.org list is not read by the Arla and kAFS
developers.  You are implementing RXOSD for OpenAFS Unix CMs and
servers.  However, we must be inclusive of all AFS implementors in any
protocol discussions.

Thank you.

Jeffrey Altman