[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Why only devdax guarantees guest data persistence ?
From: |
Dan Williams |
Subject: |
Re: [Qemu-devel] Why only devdax guarantees guest data persistence ? |
Date: |
Wed, 20 Feb 2019 08:18:57 -0800 |
On Wed, Feb 20, 2019 at 7:37 AM Stefan Hajnoczi <address@hidden> wrote:
>
> On Fri, Feb 15, 2019 at 05:09:31PM +0000, bipin.tomar--- via Qemu-devel wrote:
> > Text from "docs/nvdimm.txt" says:
> > Guest Data Persistence
> > ----------------------
> >
> > Though QEMU supports multiple types of vNVDIMM backends on Linux,
> > currently the only one that can guarantee the guest write persistence
> > is the device DAX on the real NVDIMM device (e.g., /dev/dax0.0), to
> > which all guest access do not involve any host-side kernel cache.
> >
> > I think here "host-side kernel cache" imply "page cache". Why does fsdax
> > NOT have the same persistence guarantees as devdax for vNVDIMM?
> > Both the modes avoid using page cache then why is devdax explicitly called
> > out?
>
> File systems may require msync(2)/fsync(2) to guarantee persistence even
> with DAX (just a cache flush instruction may not be enough!). Emulated
> NVDIMM devices lack an fsync interface so guests are unable to fsync the
> host file system.
>
> This is not an issue with devdax since there is no host file system.
>
> virtio-pmem is an effort to add a paravirtualized fsync-style interface
> and should solve this problem in the future:
> https://lkml.org/lkml/2019/1/9/541
A para-virtualized flush is only necessary if the host implements
caches and dirty-metadata that cannot be coordinated / flushed by
MAP_SYNC. virtio-pmem is not a solution to a problem, virtio-pmem is a
non-DAX alternative implementation of persistent memory that requires
the guest to coordinate metadata and host page cache flushing.