From: Max Reitz <mreitz@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2 3/6] qemu-img: Implement commit like QMP
Date: Thu, 10 Apr 2014 16:32:47 +0200 [thread overview]
Message-ID: <5346AB8F.7090606@redhat.com> (raw)
In-Reply-To: <20140408151458.GE6262@noname.str.redhat.com>
On 08.04.2014 17:14, Kevin Wolf wrote:
> Am 08.04.2014 um 14:50 hat Max Reitz geschrieben:
>> qemu-img should use QMP commands whenever possible in order to ensure
>> feature completeness of both online and offline image operations. As
>> qemu-img itself has no access to QMP (since this would basically require
>> just everything being linked into qemu-img), imitate QMP's
>> implementation of block-commit by using commit_active_start() and then
>> waiting for the block job to finish.
> Leaves us with the HMP commit command that uses the old bdrv_commit()
> function. I wonder if we can get rid of it by letting the HMP command
> stop the VM, do a live commit, and then restart the VM.
>
>> This new implementation does not empty the snapshot image, as opposed to
>> the old implementation using bdrv_commit(). However, as QMP's
>> block-commit apparently never did this and as qcow2 (which is probably
>> qemu's standard image format) does not even implement the required
>> function (bdrv_make_empty()), it does not seem necessary.
> In fact, I think since qcow2 has discard support it would actually be
> possible to write a sensible implementation of bdrv_make_empty(). That's
> a separate feature, though, and can go in a different patch series.
>
>> Signed-off-by: Max Reitz <mreitz@redhat.com>
>> ---
>> block/Makefile.objs | 2 +-
>> qemu-img.c | 70 ++++++++++++++++++++++++++++++++++++++---------------
>> 2 files changed, 52 insertions(+), 20 deletions(-)
>>
>> diff --git a/block/Makefile.objs b/block/Makefile.objs
>> index fd88c03..2c37e80 100644
>> --- a/block/Makefile.objs
>> +++ b/block/Makefile.objs
>> @@ -9,6 +9,7 @@ block-obj-y += snapshot.o qapi.o
>> block-obj-$(CONFIG_WIN32) += raw-win32.o win32-aio.o
>> block-obj-$(CONFIG_POSIX) += raw-posix.o
>> block-obj-$(CONFIG_LINUX_AIO) += linux-aio.o
>> +block-obj-y += mirror.o
>>
>> ifeq ($(CONFIG_POSIX),y)
>> block-obj-y += nbd.o nbd-client.o sheepdog.o
>> @@ -22,7 +23,6 @@ endif
>>
>> common-obj-y += stream.o
>> common-obj-y += commit.o
>> -common-obj-y += mirror.o
>> common-obj-y += backup.o
>>
>> iscsi.o-cflags := $(LIBISCSI_CFLAGS)
>> diff --git a/qemu-img.c b/qemu-img.c
>> index 8455994..e86911f 100644
>> --- a/qemu-img.c
>> +++ b/qemu-img.c
>> @@ -30,6 +30,7 @@
>> #include "qemu/osdep.h"
>> #include "sysemu/sysemu.h"
>> #include "block/block_int.h"
>> +#include "block/blockjob.h"
>> #include "block/qapi.h"
>> #include <getopt.h>
>>
>> @@ -682,12 +683,37 @@ fail:
>> return ret;
>> }
>>
>> +static void dummy_block_job_cb(void *opaque, int ret)
>> +{
>> +}
> Why don't we need to check the return value?
I didn't check it, because it was not called – which apparently didn't
sound strange to me at all. I checked and the much more interesting fact
is that I assumed block_job_complete() would actually complete the block
job without any further need for aio_poll(); but it doesn't. I'll fix
both things (calling aio_poll() until the CB is called and checking the
return value).
Max
> Kevin
next prev parent reply other threads:[~2014-04-10 14:33 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-08 12:50 [Qemu-devel] [PATCH v2 0/6] qemu-img: Implement commit like QMP Max Reitz
2014-04-08 12:50 ` [Qemu-devel] [PATCH v2 1/6] block-commit: Expose granularity Max Reitz
2014-04-08 15:09 ` Kevin Wolf
2014-04-08 16:20 ` Eric Blake
2014-04-10 14:40 ` Max Reitz
2014-04-08 12:50 ` [Qemu-devel] [PATCH v2 2/6] block-commit: speed is an optional parameter Max Reitz
2014-04-08 15:07 ` Kevin Wolf
2014-04-10 14:41 ` Max Reitz
2014-04-08 16:24 ` Eric Blake
2014-04-08 12:50 ` [Qemu-devel] [PATCH v2 3/6] qemu-img: Implement commit like QMP Max Reitz
2014-04-08 15:14 ` Kevin Wolf
2014-04-08 16:39 ` Eric Blake
2014-04-10 14:32 ` Max Reitz [this message]
2014-04-11 12:54 ` Kevin Wolf
2014-04-08 12:50 ` [Qemu-devel] [PATCH v2 4/6] qemu-img: Enable progress output for commit Max Reitz
2014-04-08 15:34 ` Kevin Wolf
2014-04-08 16:53 ` Eric Blake
2014-04-09 8:27 ` Kevin Wolf
2014-04-10 14:37 ` Max Reitz
2014-04-08 12:50 ` [Qemu-devel] [PATCH v2 5/6] qemu-img: Specify backing file " Max Reitz
2014-04-08 17:01 ` Eric Blake
2014-04-10 14:42 ` Max Reitz
2014-04-10 9:05 ` Fam Zheng
2014-04-10 14:45 ` Max Reitz
2014-04-08 12:50 ` [Qemu-devel] [PATCH v2 6/6] iotests: Commit tests for two-layer backing chains Max Reitz
2014-04-08 17:10 ` Eric Blake
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=5346AB8F.7090606@redhat.com \
--to=mreitz@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.