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

[Stef Bon]

2015-07-28 19:20 GMT+02:00 Simon McVittie <simon.mcvittie at collabora.co.uk>:

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


No, what I propose is a fs notify change daemon which is able to forward a
watch to individual filesystems,
and can listen to events coming from these filesystems from the backend.

Gamin can't do that. It's not maintained anymore and difficult to
understand.


>

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

I'm afraid I do not understand you here.

>> - 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.)
>

I've written that I've tried this, and also that I stopped this idea, cause
it's not the way to go.
But for your understanding, the underlying subsystem is fsnotify, and it
does handle inotify and/or fanotify, whatever is used.
So userspace should use the fsnotify api.


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

At this moment this can't work, but for CIFS in the past it worked (with
dnotiify). See:

See line 6459 in cifssmb.c in /fs/cifs in the kernel. It is disabled for
now.
But support in SMB (SMB servers do support it).

I know that the NFS4 protocol also supports it.

You must understand that the protocols do support it, but it does not work
with Linux, cause
nobody has tried it yet, and fsnotify does not let the individual
filesystems know that there is a watch set.

There are network filesystems/protocols like webdav which do not support
the setting of a watch and getting
fsevents from the backend. Webdav is build upon HTTP, and the current
version does not support the pushing of events
from the server to the client. We have to wait for version 2 of the HTTP
protocol, as the main developer of the webdav proto
told me Joe Orton.


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

Like I mentioned in the first post and here again, the filesystems like
FUSE, NFS and CIFS (and other)
are not "contacted" by fsnotify about a watch. This is by design.

So if the kernel does not do this (and beleive me there are good reasons
for), you have to do this in userspace.

Stef Bon



>
> (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.)
>

Yes that's one reason.  But there are more reasons to do this in userspace,
see above.

Stef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150728/53eb13b1/attachment.html>