qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Pankaj Gupta <pagupta@redhat.com>
To: bipin tomar <bipin.tomar@yahoo.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
	qemu-devel@nongnu.org, Dan Williams <dan.j.williams@intel.com>,
	Ross Zwisler <zwisler@kernel.org>, Jeff Moyer <jmoyer@redhat.com>
Subject: Re: [Qemu-devel] Why only devdax guarantees guest data persistence ?
Date: Wed, 20 Feb 2019 11:22:01 -0500 (EST)	[thread overview]
Message-ID: <1908184345.5542912.1550679721051.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <20190220153635.GC30403@stefanha-x1.localdomain>


> 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.

Just want to add to what Stefan already said.
 
For emulated vNVDIMM on regular storage like SSD we require an additional 
fsync on host backing file to guarantee write persistence (i.e fsync host 
page cache pages) and consistent host metadata.

If backing file is real NVDIMM, write persistence is taken care by host NVDIMM
driver and MAP_SYNC support takes care of metadata consistency in-case of guest
crash. 
> 
> This is not an issue with devdax since there is no host file system.

Yes.

> 
> 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
> 
> Stefan
> 

      parent reply	other threads:[~2019-02-20 16:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <729515484.1572396.1550250571940.ref@mail.yahoo.com>
2019-02-15 17:09 ` [Qemu-devel] Why only devdax guarantees guest data persistence ? bipin.tomar
2019-02-20 15:36   ` Stefan Hajnoczi
2019-02-20 16:18     ` Dan Williams
2019-02-20 16:22     ` Pankaj Gupta [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1908184345.5542912.1550679721051.JavaMail.zimbra@redhat.com \
    --to=pagupta@redhat.com \
    --cc=bipin.tomar@yahoo.com \
    --cc=dan.j.williams@intel.com \
    --cc=jmoyer@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=zwisler@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).