On Sat, Oct 16, 2004 at 10:11:30PM -0400, Steve Webb wrote:
> Hi everyone,
>
> Is there any documentation that specifies the various source files
> and functions that implement CODA's callback mechanism for client
> caching? I'm trying to modify the server so that it invalidates
> callbacks based on client-provided conditions. For example, A opens

The best documentation is probably the theses, Jay Kistler's thesis should document the basic callback mechanism, while Lilly Mummert's thesis would address things like volume callbacks and such.

> file f read-only, passing the server a condition that says, "Don't
> invalidate my callback unless f has undergone 3 version changes." Then,
> B opens file f read-write, makes a modification, and closes f.
> Normally, A would receive a callback invalidation from the server, but
> in my modified version, the server would fail to do so because f has
> only changed versions once since A registered interest. I'm new to

That does sound like asking for problems, since A now has a stale copy and doesn't know this, what happens if another process opens it r/w and makes a modification? The servers will reject the reintegration of the modified stale object and trigger a conflict.

> I'm currently planning to implement this on linux-2.4. Thanks in advance.

It isn't kernel dependent, all of this is handled by the userspace cachemanager. The basic file-level callback functionality in the client are in coda-src/venus/venuscb.cc, while the server side is in coda-src/vice/vicecb.cc. Then there are volume level callbacks which are taken when a client reconnects, but those probably won't really affect your situation. When a client reconnects to a volume that hasn't changed during the disconnection the client is granted a volume level callback which is broken on the first modification at which point the client reestablishes individual file-level callbacks.

Callbacks are always implicitly granted whenever a client gets attributes and/or data of a file (GetAttr/Fetch), and after a disconnection they are re-established with ValidateAttrs RPC call which simply ships a bunch of local version vectors and gets a 'valid/invalid' flag back from the server.

The volume callbacks are established when nothing has changed in a volume between 2 successful hoardwalks, if we know the volume version vector, we try to establish the volume-level callback with the ValidateVols rpc call, if any of the volumes return 'valid' (i.e. no modifications were made) we skip the validateattrs for that volume.

I hope this kind of makes sense, for the real meat refer to the PhD theses I mentioned.

Jan Received on 2004-10-23 11:35:36