summaryrefslogtreecommitdiffstats
path: root/erlang
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-02 21:13:21 +0100
commitc0a3c9ce70b98171e737e49e6dccc4457963f2ec (patch)
treece973dc3b94c918069f8157e96d78d5827ac25b2 /erlang
parentcb24ceedd8a8ef7da71cfcce6db10669de47685c (diff)
downloadlibguestfs-c0a3c9ce70b98171e737e49e6dccc4457963f2ec.tar.gz
libguestfs-c0a3c9ce70b98171e737e49e6dccc4457963f2ec.tar.xz
libguestfs-c0a3c9ce70b98171e737e49e6dccc4457963f2ec.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.
Diffstat (limited to 'erlang')
0 files changed, 0 insertions, 0 deletions