aboutsummaryrefslogtreecommitdiff
path: root/docs/nvdimm.txt
diff options
context:
space:
mode:
authorZhang Yi <yi.z.zhang@linux.intel.com>2019-04-22 08:48:48 +0800
committerEduardo Habkost <ehabkost@redhat.com>2019-04-25 14:17:36 -0300
commit119906afa5ca610adb87c55ab0d8e53c9104bfc3 (patch)
treee4456a9bfacbad8b8caf7d1d4c3d478f4e37196f /docs/nvdimm.txt
parent8cf108c5d159bccfa162a06e6abc35cfa4965781 (diff)
util/mmap-alloc: support MAP_SYNC in qemu_ram_mmap()
When a file supporting DAX is used as vNVDIMM backend, mmap it with MAP_SYNC flag in addition which can ensure file system metadata synced in each guest writes to the backend file, without other QEMU actions (e.g., periodic fsync() by QEMU). Current, We have below different possible use cases: 1. pmem=on is set, shared=on is set, MAP_SYNC supported: a: backend is a dax supporting file. - MAP_SYNC will active. b: backend is not a dax supporting file. - mmap will trigger a warning. then MAP_SYNC flag will be ignored 2. The rest of cases: - we will never pass the MAP_SYNC to mmap2 Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com> Signed-off-by: Zhang Yi <yi.z.zhang@linux.intel.com> [ehabkost: Rebased patch to latest code on master] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Wei Yang <richardw.yang@linux.intel.com> Tested-by: Wei Yang <richardw.yang@linux.intel.com> Message-Id: <20190422004849.26463-2-richardw.yang@linux.intel.com> [ehabkost: squashed documentation patch] Message-Id: <20190422004849.26463-3-richardw.yang@linux.intel.com> [ehabkost: documentation fixup] Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Pankaj Gupta <pagupta@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Diffstat (limited to 'docs/nvdimm.txt')
-rw-r--r--docs/nvdimm.txt22
1 files changed, 19 insertions, 3 deletions
diff --git a/docs/nvdimm.txt b/docs/nvdimm.txt
index 7231c2d78f..b531cacd35 100644
--- a/docs/nvdimm.txt
+++ b/docs/nvdimm.txt
@@ -144,9 +144,25 @@ 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.
+the only backend that can guarantee the guest write persistence is:
+
+A. DAX device (e.g., /dev/dax0.0, ) or
+B. DAX file(mounted with dax option)
+
+When using B (A file supporting direct mapping of persistent memory)
+as a backend, write persistence is guaranteed if the host kernel has
+support for the MAP_SYNC flag in the mmap system call (available
+since Linux 4.15 and on certain distro kernels) and additionally
+both 'pmem' and 'share' flags are set to 'on' on the backend.
+
+If these conditions are not satisfied i.e. if either 'pmem' or 'share'
+are not set, if the backend file does not support DAX or if MAP_SYNC
+is not supported by the host kernel, write persistence is not
+guaranteed after a system crash. For compatibility reasons, these
+conditions are ignored if not satisfied. Currently, no way is
+provided to test for them.
+For more details, please reference mmap(2) man page:
+http://man7.org/linux/man-pages/man2/mmap.2.html.
When using other types of backends, it's suggested to set 'unarmed'
option of '-device nvdimm' to 'on', which sets the unarmed flag of the