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

[Max Reitz <mreitz@redhat.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3098 bytes --]

On 15.01.20 13:01, Stefan Hajnoczi wrote:
> On Tue, Jan 14, 2020 at 08:24:51PM +0100, Miklos Szeredi wrote:
>> On Tue, Jan 14, 2020 at 6:13 PM Max Reitz <mreitz@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?
>>
>>> 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.
>>
>> 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.
> 
> I'm not sure I understand Max's idea.
> 
> Miklos, I think you're saying keep fuse_ino_t semantics unchanged (not
> persistent, can be reused after the last reference is dropped) and add a
> separate struct export_operations-style FUSE API to map fuse_ino_t <->
> struct file_handle.

Yes, that’d be the idea.

> We'd need to use submounts to avoid st_ino collisions in that case.

Yes, because that idea wouldn’t solve the st_ino problem.  (Only
persistent fuse_ino_t values would solve it.  This proposal is exactly
the opposite, we want them to be absolutely not persistent.)

So we’d still want submounts with separate st_devs and pass through
st_ino from the host.

> I like this approach because it requires no persistent state or extra
> in-memory data structures (if struct file_handle is cryptographically
> signed).
> 
> My biggest concern is that submounts may be complex to implement or
> introduce problems (e.g. users see the submounts and get EBUSY when
> unmounting the original directory).

I’m not quite sure what you mean, but as far as I saw so far you can
auto-unmount submounts when the root is unmounted.

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]