[OpenAFS] Re: OpenAFS callbacks

[Simon Wilkinson]

On 11 Apr 2011, at 16:20, Andrew Deason wrote:
> I think I remember looking into this on Linux a long time ago, but I
> think I discovered that inotify interaction required GPL-only symbols.
> Any idea if that's correct / still the case?

It was correct, but looking at the kernel tree it seems like things have =
improved a little bit. The notify framework is built in at the VFS =
level, so we will at least generate notification events in response to =
local actions on AFS.

Generating notification events on remote actions is a little harder (I =
know Andrew is aware of this, but thought it was worth discussing on the =
list). A callback break just tells us that we can no longer rely on our =
cached data being up to date. It doesn't tell us what's changed, or even =
mean that something has changed (a fileserver may break a callback =
simply because it has run out of space to track them). Extended =
callbacks will make all of this much easier.
=20
> And I suppose some kind of cache pinning support in the client would =
be required for any hope of
> reasonably accurate results across different clients?

Yeah - you'd need the pinning we've discussed for disconnected mode so =
that a client whose callback is broken then immediately does a =
FetchStatus to see what has changed. We'd need to be careful that things =
like beagle (which request inotify notifications for every file in a =
user's homedirectory) don't end up overwhelming a site's fileservers. =
Adding these kinds of features is likely to dramatically increase the =
number of callbacks required.

It is also here that we hit the GPL problem, because the functions we =
would need to call to generate events based on what has changed are GPL =
only and not available to us. There are a couple of ways around this, =
either by invoking a user mode helper that has the ability to create =
notification events, or by issuing VFS syscalls that simulate the =
changes made on the remote side. I'm not sure how I feel about either of =
these from a cleanliness and maintainability point of view, though.

Cheers,

Simon.