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

[Miklos Szeredi]

On Wed, Jan 15, 2020 at 4:30 PM Max Reitz <mreitz at redhat.com> wrote:
>
> 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.

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.

>
> (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.

Thanks,
Miklos