Re: [RFC PATCH 0/7] Inotify support in FUSE and virtiofs

[Amir Goldstein <amir73il@gmail.com>]

> >
> > The mistake in your premise at 1) is to state that "fuse does not
> > support persistent file handles"
> > without looking into what that statement means.
> > What it really means is that user cannot always open_by_handle_at()
> > from a previously
> > obtained file handle, which has obvious impact on exporting fuse to NFS (*).
>
> Hi Amir,
>
> What good is file handle if one can't use it for open_by_handle_at(). I
> mean, are there other use cases?

commit 44d705b0:
"...There are several ways that an application can use this information:

    1. When watching a single directory, the name is always relative to
    the watched directory, so application need to fstatat(2) the name
    relative to the watched directory.

    2. When watching a set of directories, the application could keep a map
    of dirfd for all watched directories and hash the map by fid obtained
    with name_to_handle_at(2).  When getting a name event, the fid in the
    event info could be used to lookup the base dirfd in the map and then
    call fstatat(2) with that dirfd.

    3. When watching a filesystem (FAN_MARK_FILESYSTEM) or a large set of
    directories, the application could use open_by_handle_at(2) with the fid
    in event info to obtain dirfd for the directory where event happened and
    call fstatat(2) with this dirfd.

    The last option scales better for a large number of watched directories.
    The first two options may be available in the future also for non
    privileged fanotify watchers, because open_by_handle_at(2) requires
    the CAP_DAC_READ_SEARCH capability.
"

fsnotifywait [1] has an example of use case #2.
Essentially, when watching inodes, the fanotify file identifier is not very much
different from the inotify "watch descriptor" - it identifies the watched object
and the watched object is pinned to cache as long as the inode mark is set
so file handle would not change also in fuse.

[1] https://github.com/inotify-tools/inotify-tools/pull/134

>
> IIUC, file handle for the same object can change if inode had been flushed
> out of guest cache and brought back in later. So if application say
> generated file handle for an object and saved it and later put a watch
> on that object, by that time file handle of the object might have changed
> (as seen by fuse). So one can't even use to match it with previous saved
> file handle.
>

The argument is not applicable for inode watches.
Filesystem and mount watches are not going to be supported with virtiofs
or any filesystem that does not support persistent file handles.

> So I can't use file handle for open_by_handle_at(). I can't use it to
> match it with previously saved file handle. So what can I use it for?
>
> IOW, I could not imagine supporting fanotify file handles without
> fixing the file handles properly in fuse. And it needs fixing in
> virtiofs as well as we can't trust random file handles from guest
> for regular files.
>

Partly correct statements, but when looking at the details, they are
not relevant to the case of fanotify inode watch.

Note that at the moment, fuse does not even support local fanotify
watch with file handles because of fanotify_test_fsid() - fuse does
not set f_fsid (not s_uuid), so it's not really about supporting fanotify
on fuse now.
It's about the vfs APIs for remote fsnotify that should not be inotify
specific.

Thanks,
Amir.