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" <[email protected]> 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 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
