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