On 9/11/22 17:29, Amir Goldstein wrote:
On Sun, Sep 11, 2022 at 6:16 PM Bernd Schubert
<bernd.schubert@xxxxxxxxxxx> wrote:
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?
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.
Sorry, right, it is just not passed through to user space. For the file
systems I'm working on that doesn't work at all.
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.
Hmm, I guess I need to look at it.
Thanks,
Bernd
