[systemd-devel] Suggestion for a lowlevel fsnotify change daemon.

[Simon McVittie]

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" <stefbon at 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/>