On 9/11/22 12:14, Amir Goldstein 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. 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?
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?
If anyone knows of any WIP on LOOKUP_HANDLE please let me know. Thanks, Amir. [1] https://github.com/amir73il/libfuse/commits/fuse_passthrough
Thanks, Bernd
