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

[Miklos Szeredi]

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 with the 64bit fuse_ino_t space wraparound shouldn't be an issue.

Thanks,
Miklos