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. > > 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. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
