--On Monday, April 07, 2008 12:30:06 PM -0400 Matt Benjamin
<[EMAIL PROTECTED]> wrote:
3. The term "call back" is too overloaded in AFS.
Not really. A callback(n) is always the promise of notification, or the
data object that represents that promise. Only relatively recently have
people begun to use language like "make a callback" to mean making a call
to the RXAFSCB interface, and I sort of wish they'd stop. The fileserver
issues callbacks, and breaks them; it doesn't "make" them.
Nonetheless, you make the point that in the new model, issuing an extended
notification does not mean the fileserver can forget about the callback,
since the client is not necessarily going to do so. That's actually one of
the reasons I think it's important for a client to separately advertise a
desire to receive byte-range file change notifications; if it's not going
to use them then the fileserver should use non-extended callback breaks,
for which it can then forget about the callback. The same argument
probably applies to directory change notifications.
Alternately, it might be useful to define a mechanism by which the client
can indicate, at the time an extended notification is delivered, whether it
wishes to continue receiving notifications for the file in question. This
way, a client can handle an extended file-change notification by deciding
on a case-by-case basis whether to ignore the notification (in which case
it wants to continue receiving them) or mark the whole vnode as stale (in
which case it no longer needs callbacks, at least until the next
FetchStatus).
Thanks, that is helpful. Jeff's list of pseudo-prototypes suggest a
small group of notification types and calls. Would that be unreasonable.
My sense is, people see it as more conservative, and therefore good, to
have just one call back proc. After reading my document, Jeff A. said
he wanted to commit his own change, with just a "CallBackNew" to replace
the old call back with _the_ new one.
Obviously, no one wants to introduce unecessary RPCs, but frankly, a few
clean calls should be more efficient than 1 hairy one with a switch and
opaque buffers, at the client. Faster too, I suspect. Would you
support that (Jeff H)?
I don't know about faster, but yes, it would probably be simpler to use a
small number of RPC's. For example, you might have one for metadata
changes, another for file content changes (with a byte range) and another
for directory changes (with a FID, filename, and second name, for renames).
Presumably each of these would include a notification type, with all of the
types being distinct across all of the RPC's (oh, great, another registry).
Note that I believe another use for the call back channel, as I have
stated, would be to implement:
1. an asynchronous lock request completion
2. an asynchronous revocation of delegated locks
Jeff A. asked me to remove these from the discussion to keep things
focused, and I agree that's logical, but I don't think they should be
completely ignored, either.
I agree with Jeff here. Keep locking separate; don't even make it part of
this interface. Not only should logically distinct operations be separate
RPC's, but keeping locking separate keeps the design manageable.
As discussed in previous mail, it seems that there's a natural
compression in batching notifications to one cache manager, especially
to one file, grouped as Tom says, closely in time. I assumed we would
wish to support this.
You'd think that, but the problem is that you generally can't. Cache
consistency demands that when a file's contents are changed, you break
callbacks to any online clients before the RPC that made the change
returns. That means you can't queue them up to combine later.
-- Jeff
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
