[LSF/MM TOPIC] filesystem virtualization

From: Miklos Szeredi <miklos@szeredi.hu>
To: lsf-pc@lists.linux-foundation.org
Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	Vivek Goyal <vgoyal@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: [LSF/MM TOPIC] filesystem virtualization
Date: Wed, 6 Feb 2019 14:00:35 +0100	[thread overview]
Message-ID: <CAJfpeguq60X745NnYDAKZhodLEvFRha2QTpAu6g63vJxq8SvaQ@mail.gmail.com> (raw)

This is a joint topic proposal with Vivek Goyal.

Discuss remaining issues related to exporting a filesystem from host to
guest (see virtio-fs prototype posting[1] for more background):

* How to provide strong coherency guarantees?

   - Fsnotify synchronous post op notification
   - Extend lease (delegation) API to userspace
   - Multi-component path revalidation

* Issues related to c/m/atime handling:

   - Clock synchronization between host and guest (not an fs issue, but fs
     has to deal with lack of it)

   - Could we have O_NOCMTIME open flag?

* Shared access to file data:

   - Use DAX in guest to access host page cache (mmap/munmap sections of
     file in guest address space; happens dynamically on a need basis); is
     this design reasonable?

   - Avoids memory copies and cache duplication, but host page table setup
     may have high cost.  Can that be improved?  (E.g. fault-ahead)

   - Too many VMA’s on host per qemu instance?

* File locking:

   - Host API for POSIX lock sharing?

* Ideas for the future:

   - Buffering directory operations (e.g. "tar xfz ..." with as few
     synchronous ops as possible)

[1] https://lore.kernel.org/lkml/20181210171318.16998-1-vgoyal@redhat.com/