From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39107) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAxGo-0003AL-BC for qemu-devel@nongnu.org; Tue, 13 Jan 2015 03:56:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YAxGi-00026N-OS for qemu-devel@nongnu.org; Tue, 13 Jan 2015 03:56:14 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56690) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAxGi-00025x-Hf for qemu-devel@nongnu.org; Tue, 13 Jan 2015 03:56:08 -0500 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0D8u7H7014741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 13 Jan 2015 03:56:07 -0500 Message-ID: <54B4DDA5.3070907@redhat.com> Date: Tue, 13 Jan 2015 09:56:05 +0100 From: Michal Privoznik MIME-Version: 1.0 References: <54B44B36.6040706@redhat.com> In-Reply-To: <54B44B36.6040706@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [libvirt] 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: Eric Blake , "qemu-devel@nongnu.org" , "libvir-list@redhat.com" On 12.01.2015 23:31, Eric Blake wrote: > 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=qcow2 size=10485760 encryption=off > cluster_size=65536 lazy_refcounts=off > $ qemu-img create -f qcow2 \ > -obacking_file=a.qcow2,backing_fmt=qcow2 b.qcow2 > Formatting 'b.qcow2', fmt=qcow2 size=10485760 backing_file='a.qcow2' > backing_fmt='qcow2' encryption=off cluster_size=65536 lazy_refcounts=off > $ qemu-img create -f qcow2 \ > -obacking_file=b.qcow2,backing_fmt=qcow2 c.qcow2 > Formatting 'c.qcow2', fmt=qcow2 size=10485760 backing_file='b.qcow2' > backing_fmt='qcow2' encryption=off cluster_size=65536 lazy_refcounts=off > $ 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==offset==0 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? > Yep, sounds good to me. len==offset==0 should be yet another special case. Michal