Oh, something I forgot for roman numeral I I. 4. Request-queuing/polling avoidance.
As this protocol will be serializing contending I/O operations originating at different clients, a (reliable) deferred operation mechanism should be defined to avoid client polling, and, where possible, ensure fairness. I would propose that a mechanism similar to that proposed for deferred locks in recent byte-range locking drafts, with fall-back to polling, would resolve the issue. Thanks! Matt ----- "Matt W. Benjamin" <[email protected]> wrote: > > This note looks forward to the later mail in which the signatures for > new begin/end IO routines are described e.g., RXAFS_StartAsyncFetch, > as well as back to Tom's original list of issues. > -- 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
