diff options
author | Richard W.M. Jones <rjones@redhat.com> | 2012-07-02 16:38:19 +0100 |
---|---|---|
committer | Richard W.M. Jones <rjones@redhat.com> | 2012-07-06 17:36:30 +0100 |
commit | d089d67ca383e2ec4e63e6ee1af72a8e3274d58a (patch) | |
tree | a72568517d769d804eafab0385e6b2fd2fbf2c01 /java | |
parent | f2b29513dbe0a2006ee81e144817d7ae8c1f1a4e (diff) | |
download | libguestfs-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