[Virtio-fs] Ways to uniquely and persistently identify nodes
Miklos Szeredi
mszeredi at redhat.com
Wed Jan 15 10:10:26 UTC 2020
On Wed, Jan 15, 2020 at 10:37 AM Max Reitz <mreitz at redhat.com> wrote:
> >> Or we could implement the table on top of the current system by sharing
> >> it between the client and server. Whenever the server creates a
> >> fuse_ino_t value, it then also creates a full-size handle, and returns
> >> both the handle and its corresponding fuse_ino_t value to the server.
> >> The server can use the fuse_ino_t normally most of the time, but with a
> >> catch: The client would be able to invalidate it. Then the server needs
> >> to obtain a new fuse_ino_t value for the existing handle.
> >> (Invalidating and reacquiring a fuse_ino_t value would be new FUSE
> >> operations.)
> >
> > I think you may have accidentally switched "server" and "client" in
> > the above description a couple of times.
>
> Isn’t the kernel (i.e., the guest) the client and virtiofsd the server?
It is.
So it is the server that creates a temporary fuse_ino_t and sends the
persistent handle and the temporary fuse_ino_t to the client.
The client stores both as opaque objects, and it cannot invalidate
fuse_ino_t (although it could theoretically drop it, then re-request
it based on the stored handle). The server on the other hand could
invalidate fuse_ino_t and force the client to request a new temporary
fuse_ino_t based on the persistent handle. This could be achieved, by
returning a special error value in case of an invalid fuse_ino_t.
New operations needed:
LOOKUP_WITH_HANDLE: same as LOOKUP, but returns handle in addition to
fuse_ino_t and attributes.
LOOKUP_BY_HANDLE: same as LOOKUP, but gets a handle as input.
Thanks,
Miklos
More information about the Virtio-fs
mailing list