qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] KVM "fake DAX" device flushing


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] KVM "fake DAX" device flushing
Date: Mon, 15 May 2017 10:12:12 +0100
User-agent: Mutt/1.8.0 (2017-02-23)

On Fri, May 12, 2017 at 06:53:44PM +0200, Kevin Wolf wrote:
> Am 12.05.2017 um 15:42 hat Stefan Hajnoczi geschrieben:
> > On Thu, May 11, 2017 at 05:38:40PM -0400, Rik van Riel wrote:
> > > On Thu, 2017-05-11 at 14:17 -0400, Stefan Hajnoczi wrote:
> > > > On Wed, May 10, 2017 at 09:26:00PM +0530, Pankaj Gupta wrote:
> > > > > * For live migration use case, if host side backing file is 
> > > > >   shared storage, we need to flush the page cache for the disk 
> > > > >   image at the destination (new fadvise interface,
> > > > > FADV_INVALIDATE_CACHE?) 
> > > > >   before starting execution of the guest on the destination host.
> > > > 
> > > > Good point.  QEMU currently only supports live migration with
> > > > O_DIRECT.
> > > > I think the problem was that userspace cannot guarantee consistency
> > > > in
> > > > the general case.  If you find a solution to this problem for fake
> > > > NVDIMM then maybe the QEMU block layer can also begin supporting live
> > > > migration with buffered I/O.
> > > 
> > > I'll be happy to work with you on that, independently
> > > of Pankaj's project.
> > > 
> > > It looks like the fadvise system call could be extended
> > > pretty easily with an FADV_INVALIDATE_CACHE command, the
> > > other side of which can simply hook into the existing
> > > page cache invalidation code in the kernel.
> > > 
> > > Qemu will need to know whether the invalidation succeeded,
> > > but that is something we can test for pretty easily before
> > > returning to userspace.
> > 
> > Sounds great.  I will review the long discussions that took place on
> > qemu-devel about cache invalidation for live migration - just want to
> > make sure there were no other reasons why only O_DIRECT is supported
> > :).
> 
> There are other reasons why we recommend against using non-O_DIRECT
> modes in production (including the error handling), but with respect to
> live migration, this is the only one I'm aware of.
> 
> As I already said in the private email thread, an FADV_INVALIDATE_CACHE
> should do the trick and I'd be happy to work with you guys on that.

Okay, I didn't know you and Rik had already discussed this in private.
The QEMU change is probably not difficult.

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]