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

[Jeffrey Hutzelman]

--On Wednesday, July 22, 2009 01:26:39 PM -0400 Tom Keiser 
<tkeiser@sinenomine.net> wrote:

> a) convergence of RxOSD with other protocol changes (XCB, byte-range
> locking, perhaps others)
> b) changes to cache coherence, especially DV semantics
> c) tackling the thorny issue of distributed transactions
> d) future-proofing (distributed RAID-n, journalling, rw repl, etc.)
> e) protocol design issues (RXAFS_GetOSDlocation, the means by which
> location data is XDR encoded, etc.)

These all sound like things that belong on afs3-standardization.

> f) reference implementation code issues (DAFS integration, MP-fastness
> of metadata server extensions, etc.)

At the moment, we are forced to treat OpenAFS as a de facto reference 
implementation for most existing protocol features, because there is so 
little in the way of existing specifications.  This is largely because for 
a long time, IBM treated AFS as a closed system with only one 
implementation, didn't bother to maintain protocol specifications, and paid 
relatively little attention to interoperability, even with older versions 
of AFS.  This is really a terrible way to maintain even a closed software 
product, and an even worse way to maintain an open protocol specification. 
I would very much like to see documentation of the existing protocol suite 
and formal adoption of an authoritative protocol specification, and I 
suspect many others agree with me.  I also don't see it happening anytime 
soon, because few people have many cycles to spend on AFS, and those that 
do are spending them primarily on forward-looking development rather than 
on mundane things like writing missing protocol specifications.

However, for new features, there is no reference implementation.  The only 
authoritative source for how a new protocol works is its specification.  No 
implementation can claim that if it disagrees with the spec, it's the spec 
that's got it wrong.

In any case, I assume you're referring to OpenAFS, and it is true that 
OpenAFS implementation details are best discussed here.