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

[Matt W. Benjamin]

Hi Jeff,

I need to revisit the points in this discussion, but I think I can state:

1. I accept your position that the AFS protocol we inherit presumes synchronous delivery, notwithstanding

2. I see some issues with its utility, nevertheless

3. synchronous callback delivery is a factor contributing to (but by no means equivalent to) 'strong' consistency, so

4. the consistency of AFS + XCB with async delivery is 'weaker' than AFS, albeit in a different way than rxOSD, yet

5. at the same time async delivery has desirable properties for many uses, esp. if it's combined with file locking (ditto a 'weakly' coherent OSD model); while perhaps inconsistently,

6. I actually would prefer stronger semantics than then those of AFS, when it would be useful to the clients, so, I've come to think of the problem as being about

7. Letting clients and servers negotiate a set of appropriate semantics for operating on a given object, within some given parameters meaningful to the server implementation and storage configuration--this provides a framework for moving around the weak..strong space adaptively, allowing support for a wider range of applications than any fixed semantics could provide

I see where this could feel like neologism--AFS as a storage management protocol, vs. AFS as a filesystem, AFS with different (stronger, weaker, ...) semantics than...AFS, and so on.  Yet, it also seems that it could seem inevitable, from some point of view...

Matt

----- "Jeffrey Hutzelman" <jhutz@cmu.edu> wrote:

> 
> Yeah, maybe.  We started out discussing problems with the way RxOSD
> affects 
> coherency, but between you and I, we seem to have wandered back into
> the 
> async delivery argument.
> 

-- 

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