[systemd-devel] Suggestion for a system fs change notify service.

[Lennart Poettering]

On Mo, 16.07.18 08:36, Stef Bon (stefbon at gmail.com) wrote:

> 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?

There have been previous attempts to do such a daemon, most
prominently SGI's "FAM", and GNOME's reimplementation of that called
"gamin". Both didn't end too well I figure...

I know the GNOME folks (Bastien Nocera) are making a new attempt at
this, with a strict focus on doing per-mount watches (i.e. a
user-accessible wrapper around fanotify()) and coalescing events
up the tree nicely within the queue, to deal with overruns in a
smarter way than it is usually done.

File notification on Linux is quite frankly a mess of various
competing, and very incomplete solutions. For my own work I am mostly
missing the following:

- recursive watches
- inotify: doing bit mask changes based on watch descriptor, in
  particular removing bits from watched files again
- q overruns are hard to handle, should do smarter coalescing of
  subtrees rather than simply dropping events at the end
- there's zero handling of detecting offline changes
- per mount watches (fanotify) require root
- joining /proc/self/mountinfo events to inotify events is really
  nasty
 
Thing is though, these generally can't be fixed in userspace, they
need kernel fixes, and nobody is working on that. But I am not
convinced there should be any component added to systemd about any of
this, unless they actually do something about the above
issues...

My recommendation would be: see if what Bastien does may work for you,
or whether you can convince him to open things up for your usecase
(he might have some interest there, after all GNOME uses fuse heavily
for gvfs)

Lennart

-- 
Lennart Poettering, Red Hat