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

[Matt Benjamin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

At the risk of getting really volatile discussion going, I should state
that Jeff Altman's comments on IRC, raise topics not yet addressed here:

1.  Jeff's initial reaction in public IRC was that notifications cannot
be asynchronous--we must require clients to poll for them.  Jeff A.
appears to have changed his position, but asserted the previous position
in very strong terms.  I think using the call back channel for
notifications is highly preferable to another polling interface.  Has
Jeff A.'s position in fact changed?  Is this in any way controversial?

2. Jeff stated in IRC (in response to the discussion I initially
started) that "when requesting FetchStatus or BulkStatus the client must
be able to provide a callback filter for the events that it is
interested in."  Assuming a polling interface, and also mandating
fine-grained control over notifications on a per-object basis.  Is this
mandate now retracted?  Moved to TellMeAboutYourself (not per object, 
obviously, in that case)?

3.  The term "call back" is too overloaded in AFS.  It confuses the
meaning of a call back operation and the promise to make it.  Standard
idiom, too, is about "breaking" call backs, but clearly, file change
notifications are

a. only logical if we have made the promise to call the client back, and
b. they don't break the server's promise to call back the client again

Jeffrey Hutzelman wrote:
| --On Sunday, April 06, 2008 05:39:09 PM -0400 Jeffrey Altman
| <jaltman@secure-endpoints.com> wrote:

Yes, noted.

|
| Agree.  Clients should not have to do anything to receive extended
| notifications other than advertise support for them.
|
| I'm inclined to agree, mostly.  I particularly like the idea of actually
| distributing directory changes to clients holding callbacks on a
| directory, as that could significantly improve performance in situations
| where there is heavy contention for a directory, by eliminating the need
| for clients to keep refetching that directory (if the client chooses to
| apply the update locally).
|
| I agree with some of Matt's concerns about different triggers requiring
| different extended data, but I'd really like to see a solution that does
| not require a separate RPC for each trigger.

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)?

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.

|>>
|> Why is there a range of byte range changes?  A StoreData operation
|> does not take a list of independent commits.  Each StoreData will
|> result in a BreakCallBack(). > Proc AccessChangeCallBack
|
| That's a sequence of byte ranges, to go with the sequence of FID's.  The
| idea is to let you send several updates at once, possibly on different
| FID's.  I suspect this is mostly useful on delayed callbacks.
|

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.

| Right; the CM doesn't need to know what the new ACL is; all it really
| needs to know is that the only change was to access rights.  Of course,
| currently it can't actually handle that any differently from any other
| status change, because it still needs to do a FetchStatus to obtain the
| new rights.
|
| -- Jeff

Yes, Jeff A. mostly just confused me about what I was about here.
Ignore all this.

Matt

- --

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH+kt/JiSUUSaRdSURCBrHAJoCG6pzW4zD3BghQD4TcLUZ9R/8ggCgmAJS
zSsMQUoAaKMm0GzBkaaC8Xg=
=4Gv0
-----END PGP SIGNATURE-----