block: use fdatasync instead of fsync if possible If we are flushing the caches for our image files we only care about the data (including the metadata required for accessing it) but not things like timestamp updates. So try to use fdatasync instead of fsync to implement the flush operations.
The bug now scopes all the patch set of exposing write cache flags to the guest and flush aio when the guest orders to do so: [PATCH 0/5] RHEL 5.4.z / 5.5 backports of qemu barrier support [PATCH 1/5] block: add enable_write_cache flag [PATCH 2/5] block: use fdatasync instead of fsync if possible [PATCH 3/5] block: add aio_flush operation [PATCH 4/5] ide: use bdrv_aio_flush [PATCH 5/5] virtio-blk: add volatile writecache feature
Hi Dor could you please tell me how to test this bug ? thanks
We only managed to reproduce it on Cisco's compiler, probably impossible here.
Dor, would you be able to test for QE then to verify the fix? Or provide QE with access to "cisco's compiler" ? Thanks!
I'm sorry, I was wrong about the #c7, it is mostly an optimization and not a bug, you can check the patch descriptions. I was fooled by another 'qemu barrier' BZ
It seems that this is a qcow issue so I reassign it to Kevin. We did have a problem with the ref-count code. Note that cache=wb is not supported if rhel5 for the time being so it's less painful but might indeed impose a general issue
I will close this bug with above results and comments lihuang->kwolf Do we already have BZ for the qcow2 issue ? Thanks Lijun Huang
I'm not aware of any.
(In reply to comment #29) > I'm not aware of any. I have cloned to bug 572825.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2010-0271.html