Re: File monitor problem

[Jan Kara <jack@suse.cz>]

On Wed 08-01-20 12:25:55, Amir Goldstein wrote:
> > > What I like about the fact that users don't need to choose between
> > > 'parent fid' and 'object fid' is that it makes some hard questions go away:
> > > 1. How are "self" events reported? simple - just with 'object id'
> > > 2. How are events on disconnected dentries reported? simple - just
> > > with 'object id'
> > > 3. How are events on the root of the watch reported? same answer
> > >
> > > Did you write 'directory fid' as opposed to 'parent fid' for a reason?
> > > Was it your intention to imply that events on directories (e.g.
> > > open/close/attrib) are
> > > never reported with 'parent fid' , 'name in directory'?
> >
> > Yes, that was what I thought.
> >
> > > I see no functional problem with making that distinction between directory and
> > > non-directory, but I have a feeling that 'parent fid', 'name in
> > > directory', 'object id',
> > > regardless of dir/non-dir is going to be easier to document and less confusing
> > > for users to understand, so this is my preference.
> >
> > Understood. The reason why I decided like this is that for a directory,
> > the parent may be actually on a different filesystem (so generating fid
> > will be more difficult) and also that what you get from dentry->d_parent
> > need not be the dir through which you actually reached the directory (think
> > of bind mounts) which could be a bit confusing. So I have no problem with
> > always providing 'parent fid' if we can give good answers to these
> > questions...
> >
> 
> Actually, my current code in branch fanotify_name already takes care of
> some of those cases and it is rather easy to deal with the bind mount case
> if path is available:
> 
>       if (path && path->mnt->mnt_root != dentry)
>                mnt = real_mount(path->mnt);
> 
>       /* Not reporting parent fid + name for fs root, bind mount root and
>          disconnected dentry */
>       if (!IS_ROOT(dentry) && (!path || mnt))
>                marks_mask |= fsnotify_watches_children(
>                                                dentry->d_sb->s_fsnotify_mask);
>       if (mnt)
>                marks_mask |= fsnotify_watches_children(
>                                                mnt->mnt_fsnotify_mask);
> 
> Note that a non-dir can also be bind mounted, so the concern you raised is
> actually not limited to directories.
> It is true that with the code above, FAN_ATTRIB and FAN_MODIFY (w/o path)
> could still be reported to sb mark with the parent/name under the bind mount,
> but that is not wrong at all IMO - I would say that is the expected behavior for
> a filesystem mark.

Yes, good points.

> IOW, the answer to your question, phrased in man page terminology is:
> (parent fid + name) information is not guarantied to be available except for
> FAN_DIR_MODIFY, but it may be available as extra info in addition to object fid
> for events that are possible on child.
> 
> For example, an application relying on (parent fid + name) information for
> FAN_MODIFY (e.g. for remote mirror) simply cannot get this information when
> nfsd opens a file with a disconnected dentry and writes to it.

And another good point.

> TBH, I am not convinced myself that reporting (parent fid + name) for
> directories
> is indeed easier to document/implement than treating directories different that
> non-directories, but I am going to try and implement it this way and prepare a
> draft man page update to see how it looks - I may yet change my mind after
> going through this process...

Ok, fair enough. I guess you've convinced me that both 'parent fid' and
'directory fid' approaches are somewhat messy so whatever ends up being
simplier / easier to understand is good :).

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