On 15.01.20 17:01, Miklos Szeredi wrote:
> On Wed, Jan 15, 2020 at 4:30 PM Max Reitz <mre...@redhat.com> wrote:
>>
>> On 15.01.20 16:05, Miklos Szeredi wrote:
>>> On Wed, Jan 15, 2020 at 3:58 PM Miklos Szeredi <mszer...@redhat.com> wrote:
>>>>
>>>> On Wed, Jan 15, 2020 at 1:51 PM Max Reitz <mre...@redhat.com> wrote:
>>>>>
>>>>> On 15.01.20 12:51, Miklos Szeredi wrote:
>>>>>> On Wed, Jan 15, 2020 at 11:10 AM Miklos Szeredi <mszer...@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.
>
> I'm saying that one big advantage of having the client keep hold of
> the persistent handle is that the server is free to drop its cached
> objects even before the refcount drops to zero. At that point the
> client is holding onto an invalid fuse_ino_t value and if that value
> is reused by the server, that will result in a mess.Oh, yes, sure. >> (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.) > > Yes, except we'd better use something more specific (EFUSEINOINVALID) > instead of EINVAL to make sure it doesn't conflict with real errors > returned from the operation. If we can do that, sure, that’s better. Max
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Virtio-fs mailing list Virtio-fs@redhat.com https://www.redhat.com/mailman/listinfo/virtio-fs
