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

[Stefan Hajnoczi]

On Mon, Jan 13, 2020 at 06:46:49PM +0100, Max Reitz wrote:
> (1) stat’s st_ino in the guest is not necessarily unique.  Currently, it
> just the st_ino from the host file, so if you have mounted multiple
> different filesystems in the exported directory tree, you may get
> collisions.

This must be fixed because POSIX file systems have unique and persistent
st_ino so that stat(2) can distinguish inodes from each other.

> (2) The FUSE 64-bit fuse_ino_t (which identifies an open file,
> basically) is not persistent.  It is just an index into a vector that
> contains all open inodes, and whenever virtiofsd is restarted, the
> vector is renewed.  That means that whenever this happens, all
> fuse_ino_t values the guest holds will become invalid.  (And when
> virtiofsd starts handing out new fuse_ino_t values, those will probably
> not point to the same inodes as before.)

fuse_ino_t only needs to be persistent when the FUSE_EXPORT_SUPPORT
protocol feature is enabled.  It means that nodeids persist even when
the last reference is dropped.  (If you implement an alternative
open_by_handle_at(2) approach then it would extend the semantics.)

However, it's more challenging to support power management freeze/thaw
(not a high priority since no one seems to use it) when fuse_ino_t is
not persistent.  The driver would have to do something during freeze
and/or thaw to be able to restore the FUSE session state (fuse_ino_t,
fh, etc).  If we end up not being able to implement freeze/that, I think
that would be acceptable.

> (3) name_to_handle_at()/open_by_handle_at() are implemented by FUSE just
> by handing out the fuse_ino_t value as the handle.  This is not only a
> problem as long as fuse_ino_t is not persistent (see (2)), but also in
> general, because the fuse_ino_t value is only valid (per FUSE protocol)
> as long as the inode is referenced by the guest.

open_by_handle_at() will be needed sooner or later.  For example, users
might wish to export a virtio-fs file system via an NFS server running
inside the guest.  We need this.

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/2873f9d1/attachment.sig>