Re: inotify maintenance status

[Amir Goldstein <amir73il@gmail.com>]

[Forked from https://lore.kernel.org/linux-fsdevel/20230918123217.932179-1-max.kellermann@ionos.com/]

On Mon, Sep 18, 2023 at 6:28 PM Amir Goldstein <amir73il@gmail.com> wrote:
>
> On Mon, Sep 18, 2023 at 5:23 PM Jan Kara <jack@suse.cz> wrote:
> >
> > On Mon 18-09-23 15:57:43, Max Kellermann wrote:
> > > On Mon, Sep 18, 2023 at 2:40 PM Jan Kara <jack@suse.cz> wrote:
> > > > Note that since kernel 5.13 you
> > > > don't need CAP_SYS_ADMIN capability for fanotify functionality that is
> > > > more-or-less equivalent to what inotify provides.
> > >
> > > Oh, I missed that change - I remember fanotify as being inaccessible
> > > for unprivileged processes, and fanotify being designed for things
> > > like virus scanners. Indeed I should migrate my code to fanotify.
> > >
> > > If fanotify has now become the designated successor of inotify, that
> > > should be hinted in the inotify manpage, and if inotify is effectively
> > > feature-frozen, maybe that should be an extra status in the
> > > MAINTAINERS file?
> >
> > The manpage update is a good idea. I'm not sure about the MAINTAINERS
> > status - we do have 'Obsolete' but I'm reluctant to mark inotify as
> > obsolete as it's perfectly fine for existing users, we fully maintain it
> > and support it but we just don't want to extend the API anymore. Amir, what
> > are your thoughts on this?
>
> I think that the mention of inotify vs. fanotify features in fanotify.7 man page
> is decent - if anyone wants to improve it I won't mind.
> A mention of fanotify as successor in inotify.7 man page is not a bad idea -
> patches welcome.
>
> As to MAINTAINERS, I think that 'Maintained' feels right.
> We may consider 'Odd Fixes' for inotify and certainly for 'dnotify',
> but that sounds a bit too harsh for the level of maintenance they get.
>
> I'd like to point out that IMO, man-page is mainly aimed for the UAPI
> users and MAINTAINERS is mostly aimed at bug reporters and drive-by
> developers who submit small fixes.
>
> When developers wish to add a feature/improvement to a subsystem,
> they are advised to send an RFC with their intentions to the subsystem
> maintainers/list to get feedback on their design before starting to implement.
> Otherwise, the feature could be NACKed for several reasons other than
> "we would rather invest in the newer API".
>
> Bottom line - I don't see a strong reason to change anything, but I also do
> not object to improving man page nor to switching to 'Odd Fixes' status.
>

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]:
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...

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.

Thanks,
Amir.

[1] https://github.com/amir73il/fsnotify-utils/wiki/fsnotify-TODO
[2] https://lore.kernel.org/linux-fsdevel/20230908-verflachen-neudefinition-4da649d673a9@brauner/