summaryrefslogtreecommitdiffstats
path: root/java
diff options
context:
space:
mode:
authorRichard W.M. Jones <rjones@redhat.com>2012-07-02 16:38:19 +0100
committerRichard W.M. Jones <rjones@redhat.com>2012-07-06 17:36:30 +0100
commitd089d67ca383e2ec4e63e6ee1af72a8e3274d58a (patch)
treea72568517d769d804eafab0385e6b2fd2fbf2c01 /java
parentf2b29513dbe0a2006ee81e144817d7ae8c1f1a4e (diff)
downloadlibguestfs-d089d67ca383e2ec4e63e6ee1af72a8e3274d58a.tar.gz
libguestfs-d089d67ca383e2ec4e63e6ee1af72a8e3274d58a.tar.xz
libguestfs-d089d67ca383e2ec4e63e6ee1af72a8e3274d58a.zip
daemon: Run fsync on block devices after sync (RHBZ#836710).
On Linux, sync(2) does not actually issue a write barrier, thus it doesn't force a flush of the underlying hardware write cache (or qemu's disk cache in the virtual case). This can be a problem, because libguestfs relies on running sync in the appliance, followed by killing qemu (using SIGTERM). In most cases, this is fine, because killing qemu with SIGTERM should cause it to flush out the disk cache before it exits. However we have found various bugs in qemu which cause qemu to crash while doing the flush, leaving the data unwritten (see RHBZ#836913). The solution is to issue fsync(2) to the block devices. This has a write barrier, so it ensures that qemu writes out its cache long before we get around to killing qemu. (cherry picked from commit c0a3c9ce70b98171e737e49e6dccc4457963f2ec)
Diffstat (limited to 'java')
0 files changed, 0 insertions, 0 deletions