summaryrefslogtreecommitdiffstats
path: root/python/examples
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-07 11:26:25 +0100
commit7fc03e9a45bbf87298dd98e7eb7db649e0dba4ff (patch)
treeb096e15fe9bf05140f004feab0be7e9734e9d7a5 /python/examples
parentcef7946133cef08b94814de9a1581b7c3702a3e0 (diff)
downloadlibguestfs-7fc03e9a45bbf87298dd98e7eb7db649e0dba4ff.tar.gz
libguestfs-7fc03e9a45bbf87298dd98e7eb7db649e0dba4ff.tar.xz
libguestfs-7fc03e9a45bbf87298dd98e7eb7db649e0dba4ff.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 'python/examples')
0 files changed, 0 insertions, 0 deletions