[Virtio-fs] basic questions

[Stefan Hajnoczi]

On Sat, Aug 24, 2019 at 01:09:18PM +0200, Laszlo Ersek wrote:
> Hi,
> 
> (1) The howto document at <https://virtio-fs.gitlab.io/howto-qemu.html>
> contains the following snippet:
> 
> > force use of memory sharable with the fuse daemon.
> >
> >   -m 4G,maxmem=4G -object memory-backend-file,id=mem,size=4G,mem-path=/dev/shm,share=on -numa node,memdev=mem
> 
> Why is the "maxmem" property necessary? It's not larger than the
> (implicit) "size" property of "-m", and I don't think memory hotplug is
> relevant here.

Right, maxmem is not necessary.  I have updated the howto.  It takes a
few minutes for GitLab to regenerate the website, so you might not see
the changes yet if you access it right away.

> 
> (2) what is the "fuse daemon"? Is that a reference to "virtiofsd"?

Yes, I have updated the howto to use "virtiofsd" instead.

> 
> (3) Why is a NUMA node necessary, with a memory backend file explicitly
> allocated under /dev/shm?
> 
> Will the virtio-fs device model exchange such references, over the
> socket, with virtiofsd, that point into shared memory?

The guest RAM file descriptor is sent by QEMU over the vhost-user UNIX
domain socket to virtiofsd.  virtiofsd must be able to mmap guest RAM
with the MAP_SHARED flag.

> (4) Couldn't we point mem-path to a normal (host disk based) directory?
> 
> Performance aside, that should put less pressure on host RAM, and
> otherwise work the same. Is that correct?

Yes, that should work too.

> (5) Is the shared memory area necessary for the most basic virtio-fs
> usage?

Yes, it's required because shared memory access to guest RAM allows
virtiofsd to process the virtqueues.

> (6) I seem to recall that virtio-fs allows guests to notice if files
> have changed since they last looked.
> 
> Is that functionality tied to "ireg" daemon, and to the "versiontable"
> property added in commit 8fb5b17bea63 ("virtio-fs: Allow mapping of meta
> data version table", 2019-08-23)?

Currently only virtiofsd -o cache=none guarantees fresh metadata (at a
performance cost).  The ireg daemon is experimental and incomplete, but
it will make coherent metadata cheaper in the future.

There is currently no inotify support in FUSE, so the guest does not
receive notifications when the file system changes.  Right now guests
would have to poll for changes.

> (7) Are guests required to access the virtio-fs device at the PCI level
> -- such as an MMIO region -- in order to observe async file changes, or
> is this functionality available purely at the virtio communication level
> (i.e., transport-independently)?
> 
> It doesn't seem to be explained at
> <https://stefanha.github.io/virtio/virtio-fs.html>.

Coherent shared file system access is not supported yet (that's where
the ireg daemon comes in and it's still under development).  Today
virtio-fs is good for the use case where the guest is the only one
accessing the file system.

In terms of the VIRTIO spec, everything is done at the device model
level.  Even the DAX Window is a "shared memory region", which is a
well-defined device model concept.  The MMIO and PCI transports
implement shared memory regions differently, though.

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/20190827/28d3e119/attachment.sig>