[Virtio-fs] Ways to uniquely and persistently identify nodes

[Max Reitz]

On 14.01.20 20:24, Miklos Szeredi wrote:
> On Tue, Jan 14, 2020 at 6:13 PM Max Reitz <mreitz at redhat.com> wrote:
>> What worries me most is how to pass that object around to all FUSE
>> functions, and that they all need a new interface.
> 
> You mean libfuse API?

Not only that, but also the FUSE kernel driver.

>> I just had a very fuzzy (and maybe stupid) idea: Maybe we could keep an
>> internal vector of currently active handles and then when variable-size
>> handles are enabled, fuse_ino_t would just act as an index into that vector?
>>
>> I suppose we could then use the full-size handles in all messages and
>> just hand out temporary indices to existing functions (just so we don’t
>> have to change their interface).  Server and client have their own
>> vectors, because when they communicate, only the full handles have meaning.
>>
>> 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?

> But if I'm reading this correctly, your idea is to keep the 64bit
> value on the interface (this could be just libfuse or both libfuse and
> the kernel API) and add new interfaces to establish and reestablish
> the mapping from (non-persistent) fuse_ino_t to (persistent) handle.

Yes.

Max

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/virtio-fs/attachments/20200115/bbc41208/attachment.sig>