[AFS3-std] updated extended callback draft

[Steven Jenkins]

On Sun, Oct 26, 2008 at 2:15 PM, Matt Benjamin <matt@linuxbox.com> 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/