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

[Mantas Mikulėnas]

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.

It might be useful to revive it, both inotify and fanotify have problems.
But I guess security would be a problem (how to determine which users may
receive which events).

-- 
Mantas Mikulėnas
On Jul 28, 2015 18:46, "Stef Bon" <stefbon at gmail.com> wrote:

> Hi all,
>
> for some time I have been looking at the issue why fsnotify does not work
> with network filesystems and FUSE (with a shared backend).
>
> I've found out that changes initiated on the localhost, on the filesystem
> are supported by the fs change subsystems on Linux, and events initiated at
> the backend (from another host with network fs)  are not detected. This is
> because the filesystem are not "aware" a watch has been set on an inode,
> and thus cannot act on it.
> (if they act if they are aware is another question).
>
> I've tried to tackle this in the kernel. I've made this working with a
> FUSE:
> - when a watch is set on a FUSE fs, a message is forwarded to the
> userspace daemon containing the inode and the mask. I had to add a opcode
> FUSE_FSNOTIFY.
> - the fuse fs has to react in it, by setting a watch on the backend. I
> wrote a simple overlay fs, and setting a watch on the backend is simple
> - 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.
>
> This worked but is I think not the best way to deal with it.
>
> My suggestion it to write a fs notify change service which does all the
> watching for clients, like there are already services for desktops right
> now.
>
> This service should also work with a console app like mc, but also with
> desktop environments like Gnome and KDE.
>
> 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).
> When the fs receives an event, it can send it back to the fs notify change
> service, which informs the client(s). This way the filesystem also stays up
> to date.
>
> To forward a watch and to read to incoming fsevents, a
> socket/filedescriptor is required. A FUSE fs can easily connect to it at
> startup, the in kernel filesystems need some extra. Via mountoptions parse
> the fd to the kernel?
>
> Is this something what can be added to systemd? Please let me know what
> you think of it.
>
> Stef
>
>
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150728/832899fb/attachment-0001.html>