Re: File monitor problem

From: Amir Goldstein <amir73il@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: Matthew Wilcox <willy@infradead.org>,
	Mo Re Ra <more7.rev@gmail.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Wez Furlong <wez@fb.com>,
	Matthew Bobrowski <mbobrowski@mbobrowski.org>,
	Linux API <linux-api@vger.kernel.org>
Subject: Re: File monitor problem
Date: Mon, 23 Dec 2019 21:14:53 +0200	[thread overview]
Message-ID: <CAOQ4uxhUGCLQyq76nqREETT8kBV9uNOKsckr+xmJdR9Xm=cW3Q@mail.gmail.com> (raw)
In-Reply-To: <20191223181956.GB17813@quack2.suse.cz>

On Mon, Dec 23, 2019 at 8:20 PM Jan Kara <jack@suse.cz> wrote:
>
> On Thu 19-12-19 09:33:24, Amir Goldstein wrote:
> > On Mon, Dec 16, 2019 at 5:00 PM Amir Goldstein <amir73il@gmail.com> wrote:
> > > On Wed, Dec 11, 2019 at 3:58 PM Amir Goldstein <amir73il@gmail.com> wrote:
> > > Hi Jan,
> > >
> > > I have something working.
> > >
> > > Patches:
> > > https://github.com/amir73il/linux/commits/fanotify_name
> > >
> > > Simple test:
> > > https://github.com/amir73il/ltp/commits/fanotify_name
> > >
> > > I will post the patches after I have a working demo, but in the mean while here
> > > is the gist of the API from the commit log in case you or anyone has comments
> > > on the API.
> > >
> > > Note that in the new event flavor, event mask is given as input
> > > (e.g. FAN_CREATE) to filter the type of reported events, but
> > > the event types are hidden when event is reported.
>
> Makes some sense I guess but at the same time won't this be rather
> confusing for users of the API?
>

<shrug/> I guess it will be confusing for users that we obfuscate the event
mask in the first place. I though that taking away the ability to
filter by event
type would be too much, but I can change that if you think otherwise.

> Also I've read you proposal and I'm somewhat wondering whether we are not
> overengineering this.

Possibly. Won't be my first time..

> I can see the need for FAN_DIR_MODIFIED_WITH_NAME
> (stupid name, I know) - generated when something changed with names in a
> particular directory, reported with FID of the directory and the name
> inside that directory involved with the change. Directory watching
> application needs this to keep track of "names to check". Is the name
> useful with any other type of event? _SELF events cannot even sensibly have
> it so no discussion there as you mention below. Then we have OPEN, CLOSE,
> ACCESS, ATTRIB events. Do we have any use for names with those?
>

The problem is that unlike dir fid, file fid cannot be reliably resolved
to path, that is the reason that I implemented  FAN_WITH_NAME
for events "possible on child" (see branch fanotify_name-wip).

A filesystem monitor typically needs to be notified on name changes and on
data/metadata modifications.

So maybe add just two new event types:
FAN_DIR_MODIFY
FAN_CHILD_MODIFY

Both those events are reported with name and allowed only with init flag
FAN_REPORT_FID_NAME.
User cannot filter FAN_DIR_MODIFY by part of create/delete/move.
User cannot filter FAN_CHILD_MODIFY by part of attrib/modify/close_write.
FAN_CHILD_MODIFY implies FAN_EVENT_ON_CHILD for directory watch,
but also works on sb/mount mark as if all directories are watched.

And there is nothing stopping user from requesting also _SELF events
and other events without name on the same group.

Does that sound better?

Thanks,
Amir.