On Fri, May 17, 2013 at 01:43:28PM -0700, Josh Durgin wrote: > On 05/17/2013 12:08 PM, mdroth wrote: > >On Fri, May 17, 2013 at 10:46:15AM -0500, Doug Goldstein wrote: > >>On Tue, May 14, 2013 at 4:52 PM, Michael Roth > >><mdr...@linux.vnet.ibm.com>wrote: > >> > >>>Hi everyone, > >>> > >>>The following new patches are queued for QEMU stable v1.4.2: > >>> > >>>https://github.com/mdroth/qemu/commits/stable-1.4-staging > >>> > >>>The release is planned for 05-24-2013: > >>> > >>>http://wiki.qemu.org/Planning/1.4 > >>> > >>>Please CC qemu-sta...@nongnu.org on any patches you think should be > >>>included in the release. The cut-off date is 05-20-2013 for new patches. > >>> > >>>Testing/feedback is greatly appreciated. > >>> > >>>Thanks! > >>> > >>> > >>Michael, > >> > >>I have one patch in my 1.4 stable queue. > >> > >>From: Paolo Bonzini <pbonz...@redhat.com> > >>Date: Wed, 13 Mar 2013 14:58:13 +0000 (+0100) > >>Subject: qemu-iotests: add tests for rebasing zero clusters > >>X-Git-Url: > >>http://git.qemu.org/?p=qemu.git;a=commitdiff_plain;h=acbf30ec601b1f817febc4500025b7c4181312c4 > >> > >>qemu-iotests: add tests for rebasing zero clusters > >> > >>If zero clusters are erroneously treated as unallocated, "qemu-img rebase" > >>will copy the backing file's contents onto the cluster. > >> > >>The bug existed also in image streaming, but since the root cause was in > >>qcow2's is_allocated implementation it is enough to test it with qemu-img. > >> > >>Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> > >>Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com> > >> > >>--- > >> > >> > >>It only adds a test for something that was fixed in 1.4.1 (maybe was fixed > >>by the final 1.4.0 release I can't recall). > > > >Thanks, pushed this to staging along with what should be all outstanding > >patches noted so far. > > Could you add the patch: > > commit dc7588c1eb3008bda53dde1d6b890cd299758155 > Author: Josh Durgin <josh.dur...@inktank.com> > Date: Fri Mar 29 13:03:23 2013 -0700 > > rbd: add an asynchronous flush > > The existing bdrv_co_flush_to_disk implementation uses rbd_flush(), > which is sychronous and causes the main qemu thread to block until it > is complete. This results in unresponsiveness and extra latency for > the guest. > > Fix this by using an asynchronous version of flush. This was added to > librbd with a special #define to indicate its presence, since it will > be backported to stable versions. Thus, there is no need to check the > version of librbd. > > Implement this as bdrv_aio_flush, since it matches other aio functions > in the rbd block driver, and leave out bdrv_co_flush_to_disk when the > asynchronous version is available. > > Reported-by: Oliver Francke <oli...@filoo.de> > Signed-off-by: Josh Durgin <josh.dur...@inktank.com> > Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com> > > I sent a cherry-pick of it to qemu-stable a couple days ago, although > it applies to the stable-1.4 branch cleanly. It fixes a significant > interactivity and performance problem when rbd is used with caching > enabled.
Hmm, not sure how that slipped by me. Just applied it to staging tree: https://github.com/mdroth/qemu/commits/stable-1.4-staging > > Thanks, > Josh >
