qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"libvir-list@redhat.com" <libvir-list@redhat.com>
Subject: [Qemu-devel] should active block commit ever be allowed to show 0 total progress?
Date: Mon, 12 Jan 2015 15:31:18 -0700	[thread overview]
Message-ID: <54B44B36.6040706@redhat.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2123 bytes --]

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?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

             reply	other threads:[~2015-01-12 22:31 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-12 22:31 Eric Blake [this message]
2015-01-13  8:56 ` [Qemu-devel] [libvirt] should active block commit ever be allowed to show 0 total progress? Michal Privoznik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54B44B36.6040706@redhat.com \
    --to=eblake@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).