[OpenAFS] Re: OpenAFS callbacks

[Derrick Brashear]

On Mon, Apr 11, 2011 at 2:22 PM, Simon Wilkinson <sxw@inf.ed.ac.uk> wrote:
>
> 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, s=
o we will at least generate notification events in response to local action=
s on AFS.
>
> Generating notification events on remote actions is a little harder (I kn=
ow 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 t=
his much easier.
>
>> 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 th=
at 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 (whi=
ch request inotify notifications for every file in a user's homedirectory) =
don't end up overwhelming a site's fileservers. Adding these kinds of featu=
res is likely to dramatically increase the number of callbacks required.
>
> It is also here that we hit the GPL problem, because the functions we wou=
ld need to call to generate events based on what has changed are GPL only a=
nd not available to us. There are a couple of ways around this, either by i=
nvoking a user mode helper that has the ability to create notification even=
ts, 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.

We do the latter on MacOS as there is no KPI for the fsevent kernel
subsystem. While not pretty it does work for authentication changes,
at least. For callbacks, when first investigated the desired results
were not in reach.

--=20
Derrick