Suggestion for a system fs change notify service.

[stefbon@xxxxxxxxx (Stef Bon)]

Hi,

I've written a lot of fuse filesystems, and am interested in making fs
change notify service.

fschange notify (=fsnotify for Linux) does not work for fuse
filesystems. The reason for that is that
with fuse the backend/server is not informed a fsnotify watch is set
on an inode. For local filesystems this is not a problem, with
filesystems shared with other systems (network filesystems like fuse
and cifs and nfs ea) a change initiated by another system/user is not
detected.

The sollution I've been thinking of is a local service which handles
all the fs notify requests for userspace applications (like gamin/fam
did some time ago).  When the underlying filsystem is a local fs, this
will result in the default inotify and fanotify (for Linux).

When the fs is a fuse fs, the fsnotify service sends a message to the
fuse fs to inform a watch has been set (with a certain mask). There
fore it's required that the fuse connects to the fsnotify daemon
socket when when starting (for example /run/systemd/fsnotify/sock).

The reason I choose for a connection between the fuse fs and the
fsnotify daemon through a socket is that not all information which is
interesting to the application or better the user cannot go through
the kernel. For example details about who created a file.
(user at somehost.somedomain at when on which host) are not handled by
the kernel/fsnotify subsystem. In the past I've created patches for
the fsnotify subsystem and fuse which fsnotify for fuse work. With
these patches the message is sent to the userspace fuse daemon when a
watch has been set (and also when removed or changed). This worked,
but is not the best sollution in my opinion for fschange notify.

My idea is that a low level systemd-fsnotify which offers a socket to
fuse filesystems to handle the setting of watches is the best
sollution. And of course the processing of events when something is
reported by the fuse fs: this can be local or on the backend. The fuse
fs is responsible to use protocol specific calls to set a watch on the
backend server and process anything from the server and report back to
the fsnotify service.
It's then possible to provide applications extra information.

Filsesystems like cifs and nfs are a problem. I think that they can
also contact the "systemd-fsnotify" daemon through a fd (like with
autofs) but I;ve not spent a lot of time to this issue.

Maybe in future this service can also provide info about locking too.

What do you think?

Stef Bon