[Virtio-fs] basic questions

[Stefan Hajnoczi]

On Tue, Aug 27, 2019 at 11:05:45PM +0200, Laszlo Ersek wrote:
> On 08/27/19 15:02, Stefan Hajnoczi wrote:
> > On Sat, Aug 24, 2019 at 01:09:18PM +0200, Laszlo Ersek wrote:
> >> [...]
> > [...]
> 
> Thanks for the updates for / answers to my questions (1) through (5). In
> particular I hadn't realized that it's 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.
> 
> Sorry, I was unclear. It's fine for my use case if the guest has to ask
> actively about intermittent metadata changes. My interest is not in
> notifications.
> 
> E.g. assume the guest tries to read or write a file it has opened
> earlier. (With explicit FUSE_READ / FUSE_WRITE requests, wrapped into
> the usual virtio descriptor chains.) Can the guest ask, in the read or
> write request, "please reject this request of mine if the file has
> changed since I last looked"? [1]

No, FUSE_READ/FUSE_WRITE don't support that.

> Is the "ireg" daemon, or "-o cache=none", required for that?

No.  Userspace applications that share access to a file with at least
one writer need to synchronize via file locks or out-of-band
communication.  This is how existing applications work so even if
virtio-fs offered Compare-and-Swap semantics or similar conditional I/O
primitives, I think very few applications would use them.

> However: is another (different) shared memory region planned, for the
> kind of stale metadata detection that I describe above, at [1]?

Yes, there will be a second region containing inode version numbers.
This way FUSE clients can check if the inode was modified by another
client without making a FUSE request to the server.

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/20190828/458a4871/attachment.sig>