<p dir="ltr">At first look, this seems very similar to FAM (which even supported NFSv3, using custom notifications over SunRPC).</p>
<p dir="ltr">Later I remember GNOME replaced it with Gamin and finally with local-only inotify inside glib/gvfs.</p>
<p dir="ltr">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).</p>
<p dir="ltr">-- <br>
Mantas Mikulėnas</p>
<div class="gmail_quote">On Jul 28, 2015 18:46, "Stef Bon" <<a href="mailto:stefbon@gmail.com">stefbon@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>for some time I have been looking at the issue why fsnotify does not work with network filesystems and FUSE (with a shared backend).</div><div><br></div><div>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</div><div>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.</div><div>(if they act if they are aware is another question).</div><div><br></div><div>I've tried to tackle this in the kernel. I've made this working with a FUSE:</div><div>- 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.</div><div>- 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</div><div>- 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)</div><div>- the FUSE kernel module in VFS has to trigger fsnotify call when events are pushed to the VFS by the userspace daemon.</div><div><br></div><div>This worked but is I think not the best way to deal with it.</div><div><br></div><div>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.<br></div><div><br></div><div>This service should also work with a console app like mc, but also with desktop environments like Gnome and KDE.</div><div><br></div><div>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.</div><div>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).</div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>Is this something what can be added to systemd? Please let me know what you think of it.</div><div><br></div><div>Stef </div><div><br></div></div>
<br>_______________________________________________<br>
systemd-devel mailing list<br>
<a href="mailto:systemd-devel@lists.freedesktop.org">systemd-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/systemd-devel" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/systemd-devel</a><br>
<br></blockquote></div>