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

[Max Reitz]

On 15.01.20 13:50, Stefan Hajnoczi wrote:
> 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.

OK.

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

It currently looks like we want them even less persistent, i.e. allow
the server to make the client refresh fuse_ino_t values, right?

Also, when I say “persistence“, I mostly mean “persistence through
multiple virtiofsd sessions”.  The current state is that a new session
doesn’t know what to do with the old values at all, so it’s all just broken.

(It wouldn’t be broken if we could tell the client that this is so and
make the client refresh all its fuse_ino_t values.)

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

I suppose we don’t need fuse_ino_t specifically to be persistent; it
would suffice if the client could get a persistent value (the handle)
from which to get new fuse_ino_t values when they are invalidated.

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

Sure.  But I think we should solve the first two points first because
however we do it will probably affect how we want to address this problem.

(For example, if we do decide to have handles always shared between
server and client and make fuse_ino_t a transient value that the server
can force-invalidate, then the *_handle_at() functions will be trivial
to implement.)

Max

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/virtio-fs/attachments/20200115/339ed6d6/attachment.sig>