On Sun, Sep 11, 2022 at 12:14 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>
> On Wed, Sep 23, 2020 at 10:44 AM Miklos Szeredi <miklos@xxxxxxxxxx> 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.
>
Hi Miklos,
I circled back to this. I don't suppose you know of any patches
in the works?
I was thinking about LOOKUP_HANDLE in the context of our
discussion at Plumbers on readdirplus passthrough.
What we discussed is that kernel could instantiate some FUSE inodes
(populated during readdirplus passthrough) and at some later time,
kernel will notify server about those inodes via FUSE_INSTANTIATE
or similar command, which will instantiate a fuse server inode with
pre-defined nodeid.
My thinking was to simplify a bit and require a 1-to-1 mapping
of kernel-server inode numbers to enable the feature of
FUSE_PASSTHOUGH_INODE (operations), meaning that
every FUSE inode has at least a potential backing inode which
reserves its inode number.
But I think that 1-to-1 mapping of ino is not enough and to avoid
races it is better to have 1-to-1 mapping of file handles so
FUSE_INSTANTIATE would look a bit like LOOKUP_HANDLE
but "found" server inode must match the kernel's file handle.
Is any of this making any sense to you?
Do you think that the 1-to-1 ino mapping restriction is acceptable
for the first version of inode operations passthrough?
Thanks,
Amir.
