[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [Bug 1368815] Re: qemu-img convert intermittently corrupts
From: |
Tony Breeds |
Subject: |
[Qemu-devel] [Bug 1368815] Re: qemu-img convert intermittently corrupts output images |
Date: |
Tue, 30 Sep 2014 04:51:44 -0000 |
openstack review at:
https://review.openstack.org/#/c/123957/
Qemu patches at:
http://patchwork.ozlabs.org/patch/393494/ ; and
http://patchwork.ozlabs.org/patch/393495/
** Changed in: nova
Assignee: (unassigned) => Tony Breeds (o-tony)
** Changed in: qemu
Status: New => In Progress
** Changed in: qemu
Assignee: (unassigned) => Tony Breeds (o-tony)
** Changed in: nova
Status: Triaged => In Progress
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1368815
Title:
qemu-img convert intermittently corrupts output images
Status in OpenStack Compute (Nova):
In Progress
Status in QEMU:
In Progress
Status in “qemu” package in Ubuntu:
Triaged
Status in “qemu” source package in Trusty:
Triaged
Bug description:
-- Found in releases qemu-2.0.0, qemu-2.0.2, qemu-2.1.0. Tested on
Ubuntu 14.04 using Ext4 filesystems.
The command
qemu-img convert -O raw inputimage.qcow2 outputimage.raw
intermittently creates corrupted output images, when the input image
is not yet fully synchronized to disk. While the issue has actually
been discovered in operation of of OpenStack nova, it can be
reproduced "easily" on command line using
cat $SRC_PATH > $TMP_PATH && $QEMU_IMG_PATH convert -O raw $TMP_PATH
$DST_PATH && cksum $DST_PATH
on filesystems exposing this behavior. (The difficult part of this
exercise is to prepare a filesystem to reliably trigger this race. On
my test machine some filesystems are affected while other aren't, and
unfortunately I haven't found the relevant difference between them,
yet. Possible it's timing issues completely out of userspace control
...)
The root cause, however, is the same as in
http://lists.gnu.org/archive/html/coreutils/2011-04/msg00069.html
and it can be solved the same way as suggested in
http://lists.gnu.org/archive/html/coreutils/2011-04/msg00102.html
In qemu, file block/raw-posix.c use the FIEMAP_FLAG_SYNC, i.e change
f.fm.fm_flags = 0;
to
f.fm.fm_flags = FIEMAP_FLAG_SYNC;
As discussed in the thread mentioned above, retrieving a page cache
coherent map of file extents is possible only after fsync on that
file.
See also
https://bugs.launchpad.net/nova/+bug/1350766
In that bug report filed against nova, fsync had been suggested to be
performed by the framework invoking qemu-img. However, as the choice
of fiemap -- implying this otherwise unneeded fsync of a temporary
file -- is not made by the caller but by qemu-img, I agree with the
nova bug reviewer's objection to put it into nova. The fsync should
instead be triggered by qemu-img utilizing the FIEMAP_FLAG_SYNC,
specifically intended for that purpose.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1368815/+subscriptions
- [Qemu-devel] [PATCH v5 0/7] virtio-scsi: Asynchronous cancellation, Fam Zheng, 2014/09/29
- [Qemu-devel] [PATCH v5 1/7] scsi: Drop scsi_req_abort, Fam Zheng, 2014/09/29
- [Qemu-devel] [PATCH v5 2/7] scsi-generic: Handle canceled request in scsi_command_complete, Fam Zheng, 2014/09/29
- [Qemu-devel] [PATCH v5 3/7] scsi-bus: Unify request unref in scsi_req_cancel, Fam Zheng, 2014/09/29
- [Qemu-devel] [PATCH v5 4/7] scsi: Drop SCSIReqOps.cancel_io, Fam Zheng, 2014/09/29
- [Qemu-devel] [PATCH v5 5/7] scsi: Introduce scsi_req_cancel_complete, Fam Zheng, 2014/09/29
- [Qemu-devel] [PATCH v5 6/7] scsi: Introduce scsi_req_cancel_async, Fam Zheng, 2014/09/29
- [Qemu-devel] [PATCH v5 7/7] virtio-scsi: Handle TMF request cancellation asynchronously, Fam Zheng, 2014/09/29