From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54650) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAnW8-0003JZ-Pn for qemu-devel@nongnu.org; Mon, 12 Jan 2015 17:31:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YAnW5-0005LA-Jo for qemu-devel@nongnu.org; Mon, 12 Jan 2015 17:31:24 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51592) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAnW5-0005Kw-CY for qemu-devel@nongnu.org; Mon, 12 Jan 2015 17:31:21 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0CMVJXv004823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 12 Jan 2015 17:31:20 -0500 Message-ID: <54B44B36.6040706@redhat.com> Date: Mon, 12 Jan 2015 15:31:18 -0700 From: Eric Blake MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AImBT3A46BkWC309Xkw9CGNKv05D0OHIL" Subject: [Qemu-devel] should active block commit ever be allowed to show 0 total progress? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "qemu-devel@nongnu.org" , "libvir-list@redhat.com" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AImBT3A46BkWC309Xkw9CGNKv05D0OHIL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I was trying to work on a libvirt bug, when I discovered the following: $ qemu-img create -f qcow2 a.qcow2 10M Formatting 'a.qcow2', fmt=3Dqcow2 size=3D10485760 encryption=3Doff cluster_size=3D65536 lazy_refcounts=3Doff $ qemu-img create -f qcow2 \ -obacking_file=3Da.qcow2,backing_fmt=3Dqcow2 b.qcow2 Formatting 'b.qcow2', fmt=3Dqcow2 size=3D10485760 backing_file=3D'a.qcow2= ' backing_fmt=3D'qcow2' encryption=3Doff cluster_size=3D65536 lazy_refcount= s=3Doff $ qemu-img create -f qcow2 \ -obacking_file=3Db.qcow2,backing_fmt=3Dqcow2 c.qcow2 Formatting 'c.qcow2', fmt=3Dqcow2 size=3D10485760 backing_file=3D'b.qcow2= ' backing_fmt=3D'qcow2' encryption=3Doff cluster_size=3D65536 lazy_refcount= s=3Doff $ qemu-kvm -nodefaults -qmp stdio c.qcow2 {"execute":"qmp_capabilities"} {"execute":"block-commit","arguments":{"device":"ide0-hd0","top":"c.qcow2= ","base":"b.qcow2"}} Note that it gives me the following event practically right away: {"timestamp": {"seconds": 1421101221, "microseconds": 47075}, "event": "BLOCK_JOB_READY", "data": {"device": "ide0-hd0", "len": 0, "offset": 0, "speed": 0, "type": "commit"}} and that a "query-block-jobs" confirms the "len":0,"offset":0 reporting. That is, because c.qcow2 has no sectors that differ from b.qcow2, the two files are immediately in sync. But what is annoying is that it claims that 'len' and 'offset' are equal at zero, while libvirt has code that special cases both numbers as 0 as meaning that the job has not yet started. I can fix libvirt to treat len=3D=3Doffset=3D=3D0 as treating a= job as 100% complete, but I'm wondering if qemu should be fixed to always report a non-zero length for every job that has successfully started, in order to reserve the case of a zero length for a job that has not yet determined how much needs to be done and can be treated as 0% complete. That is, does qemu have a bug for making it possible to confuse libvirt on whether a copy or active commit job has entered the second phase in contrast to not knowing if the job has started yet? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --AImBT3A46BkWC309Xkw9CGNKv05D0OHIL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJUtEs2AAoJEKeha0olJ0NqnGcH/RtZRPHRxr8kagjKtRw7+3lc +jRMv1R9Wq5GuF5msv3CqGi2GuOylBQs7Yy2ZJ/AAwpLguaDGDWKGiFEMpP8EYuw SopVaKKrauSbkly20K1wQG3EvU9+RaQ1uikfHwUgHkI/X3fZZa5PfUGzh1kI3fWG AmMtZH3j1eQTzfxfhFZzuEWg9Igl8BYVI0G12Zgy0zG1l/PoKdjqQb+2V7iWCrtB NydEpw2Ht/Yenu7WPVNJcmiEFFPwNf/SmhQSNbLUdiTVK+I+irp426uChUYzZsql jqTNFdkxf8qVsY3XbUf63c17ztPMOtzC+3qayFgO0difVTdy7o0PSAcIor785Wg= =yteb -----END PGP SIGNATURE----- --AImBT3A46BkWC309Xkw9CGNKv05D0OHIL--