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.
The purpose is "proper" NFS export support for FUSE.
"proper" being survives server restart.
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.
If anyone knows of any WIP on LOOKUP_HANDLE please let me know.
Thanks,
Amir.
[1] https://github.com/amir73il/libfuse/commits/fuse_passthrough
