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

Max Reitz mreitz at redhat.com
Wed Jan 15 15:19:06 UTC 2020


On 15.01.20 16:05, Miklos Szeredi wrote:
> On Wed, Jan 15, 2020 at 3:58 PM Miklos Szeredi <mszeredi at redhat.com> wrote:
>>
>> On Wed, Jan 15, 2020 at 1:51 PM Max Reitz <mreitz at redhat.com> wrote:
>>>
>>> On 15.01.20 12:51, Miklos Szeredi wrote:
>>>> On Wed, Jan 15, 2020 at 11:10 AM Miklos Szeredi <mszeredi at redhat.com> wrote:
>>>>
>>>>> 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.
>>>>
>>>> And that can be reduced further to a single extended LOOKUP_HANDLE,
>>>> which takes a handle as input and returns a handle in addition to the
>>>> usual stuff.  The lookup-by-handle case can be done with a special
>>>> name.  Currently "." is used for this purpose in the fuse protocol,
>>>> which is a bit confusing since it has nothing to do the "." directory
>>>> entry, but at least we don't have to introduce a new concept for this.
>>>
>>> I’m afraid I don’t quite understand.  What handle would LOOKUP_HANDLE
>>> take as input when I want to open a new file (as in, LOOKUP_WITH_HANDLE)?
>>
>> For example open("/foo/bar", ...) would do:
>>
>> lookup_handle($ROOT_HANDLE, "foo") -> { FOO_HANDLE, FOO_NODEID }
>> lookup_handle($FOO_HANDLE, "bar") -> { BAR_HANDLE, BAR_NODEID }
>> open($BAR_NODEID, ...)
> 
> Note also that this scheme makes fuse_ino_t values non-reusable,
> otherwise there could be messy conflicts with client using an old
> value that the server interprets as a new value.

But wouldn’t it just be against the protocol to use a dropped or
invalidated fuse_ino_t value?

> But with the 64bit fuse_ino_t space wraparound shouldn't be an issue.

I don’t really see the problem with the current solution of having
fuse_ino_t be an index into a vector, and old values being reused.  As
far as I understand, there is a protocol for refcount fuse_ino_t values
and the clients should not reuse values whose refcount has gone to zero.

(And we’d add to that protocol by adding a way for the server to make
the client invalidate an existing fuse_ino_t value and request a new
one.  I suppose we’d do that just by responding e.g. EINVAL if a
fuse_ino_t value is used that the server doesn’t recognize, and then the
client has to invoke lookup_(by_)handle to get a new value.)

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/971580a4/attachment.sig>


More information about the Virtio-fs mailing list