On Tue, Sep 19, 2023 at 1:43 PM Max Kellermann <max.kellermann@xxxxxxxxx> wrote: > > On Tue, Sep 19, 2023 at 12:01 PM Jan Kara <jack@xxxxxxx> wrote: > > 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. > > The wd is a simple "int" which is the return value of the system call, > and it's part of "struct inotify_event". One system call for > registering it, one system call fo reading it. > > From fanotify, I read a "struct fanotify_event_metadata", and then > check variable-length follow-up structs, iterable those follow-up > structs, find the one with "info_type==FAN_EVENT_INFO_TYPE_FID", now I > have a "fsid" of type "__kernel_fsid_t" (a struct containing two > 32-bit integers) and a "file_handle" (a variable-length opaque BLOB). > What do I do with these? > > The answer appears to be: when I registered, I should have obtained > the fsid (via statfs()) and the file_handle (via name_to_handle_at()). > That's three extra system calls. One statfs(), and twice > name_to_handle_at(), because the first one is needed to get the length > of the buffer I need to allocate for the file_handle (and hope my > filesystem supports file_handles, because apparently that's an > optional feature). Just look at the name_to_handle_at() manpage for > some horrors of its complexity. > > Imagine how much more complex the data structure for looking up the > modified file is: inotify has an int as the lookup key, and fanotify > has two integers plus a variable-length BLOB. > You are not describing a technical problem. Any API complexity can be hidden from users with userspace libraries. You can use the inotify-tools lib if you prefer. I assure you that the added complexity to the API was not done to make your life harder. inotify API has several design flaws and fanotify API extensions were designed to address those flaws. > > But if you want to monitor multiple filesystems > > I can monitor multiple filesystems with inotify. > > > or if you have priviledged process that can open by handle > > Getting an already-opened file descriptor, or just the file_handle, is > certainly an interesting fanotify feature. But that could have easily > been added to inotify with a new "mask" flag for the > inotify_add_watch() function. > "could have easily been added" is not a statement that I am willing to accept. You are saying that because you do not understand the complexity involved and that is fine - you can ask. The things that you are complaining about in the API are the exact things that were needed to make the advanced features work. Beyond that, it is a matter of API consolidation - We prefer to maintain a single unified API that can cover all the use cases over maintaining several overlapping APIs. The complexity added to the API for simple use cases can be mitigated with user libraries - it is not a good reason IMO to keep maintaining an old limited API in parallel to a new improved one. Thanks, Amir.
