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