Re: [Qemu-devel] [libvirt] should active block commit ever be allowed to show 0 total progress?

[Michal Privoznik <mprivozn@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