[AFS3-std] File Server/Cache Manager Extended Status Information

[Jeffrey Hutzelman]

--On Monday, April 07, 2008 12:30:06 PM -0400 Matt Benjamin 
<matt@linuxbox.com> 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