Re: FAN_REPORT_CHILD_FID

[Jan Kara <jack@suse.cz>]

Hi Amir!

On Sun 11-07-21 20:02:29, Amir Goldstein wrote:
> I am struggling with an attempt to extend the fanotify API and
> I wanted to ask your opinion before I go too far in the wrong direction.
> 
> I am working with an application that used to use inotify rename
> cookies to match MOVED_FROM/MOVED_TO events.
> The application was converted to use fanotify name events, but
> the rename cookie functionality was missing, so I am carrying
> a small patch for FAN_REPORT_COOKIE.
> 
> I do not want to propose this patch for upstream, because I do
> not like this API.
> 
> What I thought was that instead of a "cookie" I would like to
> use the child fid as a way to pair up move events.
> This requires that the move events will never be merged and
> therefore not re-ordered (as is the case with inotify move events).
> 
> My thinking was to generalize this concept and introduce
> FAN_REPORT_CHILD_FID flag. With that flag, dirent events
> will report additional FID records, like events on a non-dir child
> (but also for dirent events on subdirs).

I'm starting to get lost in what reports what so let me draw a table here:

Non-directories
				DFID	FID	CHILD_FID
ACCESS/MODIFY/OPEN/CLOSE/ATTRIB parent	self	self
CREATE/DELETE/MOVE		-	-	-
DELETE_SELF/MOVE_SELF		x	self	self
('-' means cannot happen, 'x' means not generated)

Directories
				DFID	FID	CHILD_FID
ACCESS/MODIFY/OPEN/CLOSE/ATTRIB self	self	self
CREATE/DELETE/MOVE		self	self	target
DELETE_SELF/MOVE_SELF		x	self	self

Did I get this right?

I guess "CHILD_FID" seems somewhat confusing as it isn't immediately clear
from the name what it would report e.g. for open of a non-directory. Maybe
we could call it "TARGET_FID"? Also I'm not sure it needs to be exclusive
with FID. Sure it doesn't make much sense to report both FID and CHILD_FID
but does the exclusivity buy us anything? I guess I don't have strong
opinion either way, I'm just curious.
 
> Either FAN_REPORT_CHILD_FID would also prevent dirent events
> from being merged or we could use another flag for that purpose,
> but I wasn't able to come up with an idea for a name for this flag :-/
> 
> I sketched this patch [1] to implement the flag and to document
> the desired semantics. It's only build tested and I did not even
> implement the merge rules listed in the commit message.
> 
> [1] https://github.com/amir73il/linux/commits/fanotify_child_fid

WRT changes to merging: Whenever some application wants to depend on the
ordering of events I'm starting to get suspicious. What is it using these
events for? How is renaming different from linking a file into a new dir
and unlinking it from the previous one which is a series of events that
could be merged? Also fanotify could still be merging events happening
after rename to events before rename. Can the application tolerate that?
Inotify didn't do this because it is always merging only to the last event
in the queue.

When we were talking about FID events in the past (in the context of
directory events) we always talked about application just maintaining a set
of dirs (plus names) to look into. And that is safe and sound. But what you
talk about now seems rather fragile at least from the limited information I
have about your usecase...

> There are other benefits from FAN_REPORT_CHILD_FID which are
> not related to matching move event pairs, such as the case described
> in this discussion [2], where I believe you suggested something along
> the lines of FAN_REPORT_CHILD_FID.
> 
> [2] https://lore.kernel.org/linux-fsdevel/CAOQ4uxhEsbfA5+sW4XPnUKgCkXtwoDA-BR3iRO34Nx5c4y7Nug@mail.gmail.com/

Yes, I can see FAN_REPORT_CHILD_FID (or however we call it) can be useful
at times (in fact I think we made a mistake that we didn't make reported
FID to always be what you now suggest as CHILD_FID, but we found that out
only when DFID+NAME implementation settled so that train was long gone).
So I have no problem with that functionality as such.

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR