Re: Persistent FUSE file handles (Was: virtiofs uuid and file handles)

[Amir Goldstein <amir73il@gmail.com>]

On Sun, Sep 11, 2022 at 6:16 PM Bernd Schubert
<bernd.schubert@fastmail.fm> wrote:
>
>
>
> On 9/11/22 12:14, Amir Goldstein wrote:
> > On Wed, Sep 23, 2020 at 10:44 AM Miklos Szeredi <miklos@szeredi.hu> wrote:
> >>
> >> One proposal was to add  LOOKUP_HANDLE operation that is similar to
> >> LOOKUP except it takes a {variable length handle, name} as input and
> >> returns a variable length handle *and* a u64 node_id that can be used
> >> normally for all other operations.
> >>
> >> The advantage of such a scheme for virtio-fs (and possibly other fuse
> >> based fs) would be that userspace need not keep a refcounted object
> >> around until the kernel sends a FORGET, but can prune its node ID
> >> based cache at any time.   If that happens and a request from the
> >> client (kernel) comes in with a stale node ID, the server will return
> >> -ESTALE and the client can ask for a new node ID with a special
> >> lookup_handle(fh, NULL).
> >>
> >> Disadvantages being:
> >>
> >>   - cost of generating a file handle on all lookups
> >>   - cost of storing file handle in kernel icache
> >>
> >> I don't think either of those are problematic in the virtiofs case.
> >> The cost of having to keep fds open while the client has them in its
> >> cache is much higher.
> >>
> >
> > I was thinking of taking a stab at LOOKUP_HANDLE for a generic
> > implementation of persistent file handles for FUSE.
> >
> > The purpose is "proper" NFS export support for FUSE.
> > "proper" being survives server restart.
>
> Wouldn't fuse just need to get struct export_operations additions to
> encode and decode handles?
>

FUSE already implements those, but not in a "proper" way, because
there is nothing guaranteeing the persistence of the FUSE file handles.

As a result, when exporting some FUSE fs to NFS and the server is
restarted, NFS client may read a file A and get the content of file B,
because after server restart, FUSE file B got the node id that file A
had before restart.

This is not a hypothetical use case, I have seen this happen.

> >
> > I realize there is an ongoing effort to use file handles in the virtiofsd
> > instead of open fds and that LOOKUP_HANDLE could assist in that
> > effort, but that is an added benefit.
> >
> > I have a C++ implementation [1] which sort of supports persistent
> > file handles, but not in a generic manner.
>
> How does this interact with exportfs?
>

It makes use of internal fs knowledge to encode/decode ext4/xfs
file handles into the 64bit FUSE node id.

This sort of works, but it is not generic.

Thanks,
Amir.