On Sun, Oct 26, 2008 at 2:15 PM, Matt Benjamin <[EMAIL PROTECTED]> wrote: ... > > Nb., recent reviewers, I've left the names of AFSCB_Cancel_LostMyMind > and AFSCB_Cancel_IHateYou as previously defined, by request of the author. >
I suggest that we change those two names as follows: AFSCB_Cancel_LostMyMind to AFSCB_Cancel_OutOfCallbacks AFSCB_Cancel_IHateYou to AFSCB_Cancel_RevokedByAdmin While I think the current names are cute, the suggested names are more descriptive & self-documenting; thus we can reduce the need for comments that clarify what those two do. I believe that: An implementation MAY define make window selection adaptive. is more clear as: An implementation MAY make window selection adaptive. But are there any bounds on that, other than the 100ms < window size < small number of seconds (the latter of which should be defined -- I'll suggest 5 seconds) The change in semantics needs discussion, so I've extracted it in its entirety (and made a few minor edits): ==begin 3.4.6 Asynchronous Delivery A server implementation MAY deliver extended callback notifications asynchronously with respect to the operation which triggered the notification. Traditionally, AFS callbacks have been delivered synchronously, in the sense that the callback invalidate invocation has been required to be delivered to eligible clients before the triggering operation/RPC completes. The primary effect of synchronous callback delivery is simplication of the fileserver, but there are potential implications for callback consistency. This proposal asserts that the resulting effect on cache consistency across clients is negligible, because, in particular with sync-on-close semantics, AFS clients are permitted to independently and disjointly cache changes for arbitrary periods of time. Hence synchronous callback execution does not provide a true guarantee of distributed data or metadata consistency (while it does impose a potential performance penalty for mutating operations). Synchronous callback delivery does bound the scope of submitted changes not yet visible to interested, connected clients of one fileserver to those being concurrently executed and invalidated by the sum of its executing threads. For asynchronous callback delivery, we propose that this guarantee is equivalent to a bound on the total number of outstanding asynchronous callback events. We propose that an implementation MUST enforce an implementation-specific limit on the number of outstanding callbacks, falling back to synchronous delivery if the limit is exceeded. ==end Could you elaborate on your assertion that synchronous write-on-close is equivalent to bounded asynchronous writes? Specifically, could you provide information on the write-on-close vs write-through (or other semantic models) that you are assuming for 'asynchronous callback events'? Thanks, Steven Jenkins End Point Corporation http://www.endpoint.com/ _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
