On Tue, Sep 19, 2023 at 1:01 PM Jan Kara <jack@xxxxxxx> wrote: > > On Tue 19-09-23 11:08:21, Max Kellermann wrote: > > On Tue, Sep 19, 2023 at 9:17 AM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > As my summary above states, it is correct that fanotify does not > > > yet fully supersedes inotify, but there is a plan to go in this direction, > > > hence, inotify is "being phased out" it is not Obsolete nor Deprecated. > > > > I agree that if inotify is to be phased out, we should concentrate on fanotify. > > > > I'm however somewhat disappointed with the complexity of the fanotify > > API. I'm not entirely convinced that fanotify is a good successor for > > inotify, or that inotify should really be replaced. The additional > > features that fanotify has could have been added to inotify instead; I > > don't get why this needs an entirely new API. Of course, I'm late to > > complain, having just learned about (the unprivileged availability of) > > fanotify many years after it has been invented. > > > > System calls needed for one inotify event: > > - read() > > > > System calls needed for one fanotify event: > > - read() > > - (do some magic to look up the fsid - > > https://github.com/martinpitt/fatrace/blob/master/fatrace.c implements > > a lookup table, yet more complexity that doesn't exist with inotify) > > - open() to get a file descriptor for the fsid > > - open_by_handle_at(fsid_fd, fid.handle) > > - readlink("/proc/self/fd/%d") (which adds a dependency on /proc being mounted) > > - close(fd) > > - close(fsid_fd) > > > > I should mention that this workflow still needs a privileged process - > > yes, I can use fanotify in an unprivileged process, but > > open_by_handle_at() is a privileged system call - it requires > > CAP_DAC_READ_SEARCH. Without it, I cannot obtain information on which > > file was modified, can I? > > There is FAN_REPORT_NAME, but it gives me only the name of the > > directory entry; but since I'm watching a lot of files and all of them > > are called "memory.events.local", that's of no use. > > > > Or am I supposed to use name_to_handle_at() on all watched files to > > roll my own lookup? (The name_to_hamdle_at() manpage doesn't make me > > confident it's a reliable system call; it sounds like it needs > > explicit support from filesystems.) > > So with inotify event, you get back 'wd' and 'name' to identify the object > where the event happened. How is this (for your usecase) different from > getting back 'fsid + handle' and 'name' back from fanotify? In inotify case > you had to somehow track wd -> path linkage, with fanotify you need to > track 'fsid + handle' -> path linkage. > And if you want to see an implementation of a drop-in replacement of inotify/fanotify, you can take a look at: https://github.com/inotify-tools/inotify-tools/pull/134 And specifically the first commit 41b2ec4 ("Index watches by fanotify fid") to understand why fid is a drop-in replacement for wd. > > > FAN_REPORT_FID is designed in a way to be almost a drop in replacement > > > for inotify watch descriptors as an opaque identifier of the object, except that > > > fsid+fhanle provide much stronger functionality than wd did. > > > > How is it stronger? > > For your particular usecase I don't think there's any advantage of > fsid+fhandle over plain wd. But if you want to monitor multiple filesystems > or if you have priviledged process that can open by handle, or a standard > filesystem where handles are actually persistent, then there are benefits. > Those cases are demonstrated in the --filesystem functionality of the pull request above, which handles "dynamic watches" instead of having to setup watches recursively on all subdirs. Thanks, Amir.
