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

[Stefan Hajnoczi]

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

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

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

Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/virtio-fs/attachments/20200115/41d1eae1/attachment.sig>