On 28/07/15 17:28, Mantas Mikulėnas wrote: > At first look, this seems very similar to FAM (which even supported > NFSv3, using custom notifications over SunRPC). > > Later I remember GNOME replaced it with Gamin and finally with > local-only inotify inside glib/gvfs.
What GLib actually uses is an abstraction with multiple backends, including inotify (the default on Linux) and FAM; so in principle it could have a backend for some new thing, or even use inotify for "normal local filesystems" and the new backend for other mounts. However... > On Jul 28, 2015 18:46, "Stef Bon" <stef...@gmail.com> wrote: >> - I had to add some calls to the fuse library to "push" changes to >> the VFS where there is no direct related call from the VFS. (files >> are added and/or files are changed) >> - the FUSE kernel module in VFS has to trigger fsnotify call when >> events are pushed to the VFS by the userspace daemon. If you're adding a monitoring/notification call to FUSE, would it be out of the question for the user-space API to it to be exactly "use inotify"? (Or fanotify, or whatever is believed to be the right user-space API for file monitoring these days.) >> It should also be able to "forward" a watch to a filesystem like >> FUSE and cifs and nfs, so that they "know" a watch has been set. >> They can act then on it, by forwarding the watch to the backend. SMB >> does upport this, NFS4 also, and you can make FUSE also support >> it(depending the protocol). If the in-kernel implementation of NFS or CIFS isn't enhanced to support monitoring, this can't work. If the in-kernel implementation of NFS or CIFS *is* enhanced to support monitoring, is there any reason for the kernel not to present the resulting information to user-space via inotify? In other words, is there a reason why a user-space service is necessary? (I realise that one possible reason for a user-space service is so that it can aggregate all the periodic polling, on filesystems that don't have anything better you can do - that's why FAM had a daemon, if I remember correctly.) -- Simon McVittie Collabora Ltd. <http://www.collabora.com/> _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
