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. > 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. _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
