On Wed, Sep 23, 2020 at 10:44 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>
> On Wed, Sep 23, 2020 at 4:49 AM Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>
> > I think that the proper was to implement reliable persistent file
> > handles in fuse/virtiofs would be to add ENCODE/DECODE to
> > FUSE protocol and allow the server to handle this.
>
> Max Reitz (Cc-d) is currently looking into this.
>
> 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
I never ran into a local fs implementation where this was expensive.
> - 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.
>
Sounds good.
I suppose flock() does need to keep the open fd on server.
Are there any other states for an open fd that must be preserved?
Thanks,
Amir.
