On Tue, Sep 19, 2023 at 12:48 PM Jan Kara <jack@xxxxxxx> wrote: > > On Mon 18-09-23 21:05:11, Amir Goldstein wrote: > > [Forked from https://lore.kernel.org/linux-fsdevel/20230918123217.932179-1-max.kellermann@xxxxxxxxx/] > ... > > BTW, before we can really mark inotify as Obsolete and document that > > inotify was superseded by fanotify, there are at least two items on the > > TODO list [1]: > > Yeah, as I wrote in the original thread, I don't feel like inotify should > be marked as obsolete (at least for some more time) so we are on the same > page here I think. > > > 1. UNMOUNT/IGNORED events > > 2. Filesystems without fid support > > > > MOUNT/UNMOUNT fanotify events have already been discussed > > and the feature has known users. > > > > Christian has also mentioned [1] the IN_UNMOUNT use case for > > waiting for sb shutdown several times and I will not be surprised > > to see systemd starting to use inotify for that use case before too long... > > Yup, both FAN_UNMOUNT and FAN_IGNORED should be easy. Unlike inotify, I'd > just make these explicit events you can opt into and not something you > always get. > > > Regarding the second item on the TODO list, we have had this discussion > > before - if we are going to continue the current policy of opting-in to > > fanotify (i.e. tmpfs, fuse, overlayfs, kernfs), we will always have odd > > filesystems that only support inotify and we will need to keep supporting > > inotify only for the users that use inotify on those odd filesystems. > > > > OTOH, if we implement FAN_REPORT_DINO_NAME, we could > > have fanotify inode mark support for any filesystem, where the > > pinned marked inode ino is the object id. > > Is it a real problem after your work to allow filehandles that are not > necessarily usable for NFS export or open_by_handle()? As far as I remember > fanotify should be now able to handle anything that provides f_fsid in its Not exactly. We still have a requirement for non-empty dentry->d_sb->s_export_op in fanotify_test_fid(), to align with the same requirement for AT_HANDLE_FID support. > statfs(2) call. And as I'm checking filesystems not setting fsid currently are: > > afs, coda, nfs - networking filesystems where inotify and fanotify have > dubious value anyway > > configfs, debugfs, devpts, efivarfs, hugetlbfs, openpromfs, proc, pstore, > ramfs, sysfs, tracefs - virtual filesystems where fsnotify functionality is > quite limited. But some special cases could be useful. Adding fsid support > is the same amount of trouble as for kernfs - a few LOC. In fact, we > could perhaps add a fstype flag to indicate that this is a filesystem > without persistent identification and so uuid should be autogenerated on > mount (likely in alloc_super()) and f_fsid generated from sb->s_uuid. > This way we could handle all these filesystems with trivial amount of > effort. This sounds good to me. I have a vague memory of suggesting the same and I think Christian had objections, but I may be remembering wrong. Possibly, the same opt-in fstype flag could allow also trivial AT_HANDLE_FID support with the default export_encode_fh()? > > freevxfs - the only real filesystem without f_fsid. Trivial to handle one > way or the other. > > So I don't think we need new uAPI additions to finish off this TODO item. Yes, I'd love that. I can try to post something if there are no objections. Thanks, Amir.
