qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: Alberto Garcia <berto@igalia.com>, qemu-devel@nongnu.org
Cc: Stefan Hajnoczi <stefanha@redhat.com>, qemu-block@nongnu.org
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 4/6] block: Support streaming to an intermediate layer
Date: Wed, 15 Apr 2015 18:09:18 +0200	[thread overview]
Message-ID: <552E8D2E.8060103@redhat.com> (raw)
In-Reply-To: <be59fd9d9bf0f080eb172972319f12f199913029.1428503789.git.berto@igalia.com>

On 08.04.2015 16:43, Alberto Garcia wrote:
> This makes sure that the image we are steaming into is open in
> read-write mode during the operation.
>
> Operation blockers are also set in all intermediate nodes, since they
> will be removed from the chain afterwards.
>
> Finally, this also unblocks the stream operation in backing files.
>
> Signed-off-by: Alberto Garcia <berto@igalia.com>
> ---
>   block.c        |  4 +++-
>   block/stream.c | 36 ++++++++++++++++++++++++++++++++++++
>   2 files changed, 39 insertions(+), 1 deletion(-)
>
> diff --git a/block.c b/block.c
> index 25289ef..e892cb4 100644
> --- a/block.c
> +++ b/block.c
> @@ -1240,9 +1240,11 @@ void bdrv_set_backing_hd(BlockDriverState *bs, BlockDriverState *backing_hd)
>               backing_hd->drv ? backing_hd->drv->format_name : "");
>   
>       bdrv_op_block_all(bs->backing_hd, bs->backing_blocker);
> -    /* Otherwise we won't be able to commit due to check in bdrv_commit */
> +    /* Otherwise we won't be able to commit or stream */
>       bdrv_op_unblock(bs->backing_hd, BLOCK_OP_TYPE_COMMIT_TARGET,
>                       bs->backing_blocker);
> +    bdrv_op_unblock(bs->backing_hd, BLOCK_OP_TYPE_STREAM,
> +                    bs->backing_blocker);
>   out:
>       bdrv_refresh_limits(bs, NULL);
>   }
> diff --git a/block/stream.c b/block/stream.c
> index 37bfd8b..327d964 100644
> --- a/block/stream.c
> +++ b/block/stream.c
> @@ -33,6 +33,8 @@ typedef struct StreamBlockJob {
>       BlockDriverState *base;
>       BlockdevOnError on_error;
>       char *backing_file_str;
> +    int bs_flags;
> +    Error *blocker;
>   } StreamBlockJob;
>   
>   static int coroutine_fn stream_populate(BlockDriverState *bs,
> @@ -88,8 +90,15 @@ static void stream_complete(BlockJob *job, void *opaque)
>   {
>       StreamBlockJob *s = container_of(job, StreamBlockJob, common);
>       StreamCompleteData *data = opaque;
> +    BlockDriverState *i;

I'd prefer another name. "i" is generally used for integers used as indices.

>       BlockDriverState *base = s->base;
>   
> +    /* Remove all blockers set in stream_start() */
> +    for (i = job->bs->backing_hd; i && i != s->base; i = i->backing_hd) {
> +        bdrv_op_unblock_all(i, s->blocker);
> +    }
> +    error_free(s->blocker);
> +
>       if (!block_job_is_cancelled(&s->common) && data->reached_end &&
>           data->ret == 0) {
>           const char *base_id = NULL, *base_fmt = NULL;
> @@ -103,6 +112,11 @@ static void stream_complete(BlockJob *job, void *opaque)
>           close_unused_images(job->bs, base, base_id);
>       }
>   
> +    /* Reopen the image back in read-only mode if necessary */
> +    if (s->bs_flags != bdrv_get_flags(job->bs)) {
> +        bdrv_reopen(job->bs, s->bs_flags, NULL);
> +    }
> +
>       g_free(s->backing_file_str);
>       block_job_completed(&s->common, data->ret);
>       g_free(data);
> @@ -246,7 +260,9 @@ void stream_start(BlockDriverState *bs, BlockDriverState *base,
>                     BlockCompletionFunc *cb,
>                     void *opaque, Error **errp)
>   {
> +    BlockDriverState *i;

Again, just "i" is a bit strange to read...

>       StreamBlockJob *s;
> +    int orig_bs_flags;
>   
>       if ((on_error == BLOCKDEV_ON_ERROR_STOP ||
>            on_error == BLOCKDEV_ON_ERROR_ENOSPC) &&
> @@ -255,13 +271,33 @@ void stream_start(BlockDriverState *bs, BlockDriverState *base,
>           return;
>       }
>   
> +    /* Make sure that the image in opened in read-write mode */

s/in/is/

> +    orig_bs_flags = bdrv_get_flags(bs);
> +    if (!(orig_bs_flags & BDRV_O_RDWR)) {

I feel like we don't want to do this if we're not streaming to an 
intermediate layer but to the top layer (because that means there is 
some reason for the BDS to be read-only beyond it just being a backing BDS).

> +        Error *local_err = NULL;
> +        bdrv_reopen(bs, orig_bs_flags | BDRV_O_RDWR, &local_err);
> +        if (local_err != NULL) {
> +            error_propagate(errp, local_err);

Shorter alternative: "if (bdrv_reopen(bs, orig_bs_flags | BDRV_O_RDWR, 
errp) < 0)".

> +            return;
> +        }
> +    }
> +
>       s = block_job_create(&stream_job_driver, bs, speed, cb, opaque, errp);
>       if (!s) {
>           return;
>       }
>   
> +    /* Block all intermediate nodes between bs and base, because they
> +     * will disappear from the chain after this operation */

Hm, do we really need to? There's a difference between "it doesn't make 
sense, but it works if you want to" and "it will break". Shouldn't it be 
enough that the intermediate nodes are all read-only anyway (hopefully)?

But then again, it probably won't hurt and I don't really want to think 
about the implications of trying to run a block-commit or a separate 
block-stream on the chain...

> +    error_setg(&s->blocker, "blocked by the block-stream operation in '%s'",
> +               bdrv_get_node_name(bs));

Why not bdrv_get_device_or_node_name()?

> +    for (i = bs->backing_hd; i != base && i != NULL; i = i->backing_hd) {
> +        bdrv_op_block_all(i, s->blocker);
> +    }
> +
>       s->base = base;
>       s->backing_file_str = g_strdup(backing_file_str);
> +    s->bs_flags = orig_bs_flags;
>   
>       s->on_error = on_error;
>       s->common.co = qemu_coroutine_create(stream_run);

So, in general this patch looks OK to me. I had some nitpicks 
(..._device_or_node_name, "i", ...), and I think we should not try to 
re-open the target BDS if streaming to the top level.

Max

  reply	other threads:[~2015-04-15 16:09 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-08 14:43 [Qemu-devel] [PATCH v3 0/6] Support streaming to an intermediate layer Alberto Garcia
2015-04-08 14:43 ` [Qemu-devel] [PATCH 1/6] block: keep a list of block jobs Alberto Garcia
2015-04-15 14:29   ` [Qemu-devel] [Qemu-block] " Max Reitz
2015-04-08 14:43 ` [Qemu-devel] [PATCH 2/6] block: allow block jobs in any arbitrary node Alberto Garcia
2015-04-15 15:22   ` [Qemu-devel] [Qemu-block] " Max Reitz
2015-04-16  8:20     ` Alberto Garcia
2015-04-08 14:43 ` [Qemu-devel] [PATCH 3/6] block: never cancel a streaming job without running stream_complete() Alberto Garcia
2015-04-15 15:29   ` [Qemu-devel] [Qemu-block] " Max Reitz
2015-04-08 14:43 ` [Qemu-devel] [PATCH 4/6] block: Support streaming to an intermediate layer Alberto Garcia
2015-04-15 16:09   ` Max Reitz [this message]
2015-04-16  9:36     ` [Qemu-devel] [Qemu-block] " Alberto Garcia
2015-04-16 12:27       ` Eric Blake
2015-04-16 12:34         ` Alberto Garcia
2015-04-17  8:02           ` Kevin Wolf
2015-04-16 14:30     ` Alberto Garcia
2015-04-17 12:46       ` Max Reitz
2015-04-08 14:43 ` [Qemu-devel] [PATCH 5/6] block: Add QMP support for " Alberto Garcia
2015-04-15 16:17   ` [Qemu-devel] [Qemu-block] " Max Reitz
2015-04-08 14:43 ` [Qemu-devel] [PATCH 6/6] docs: Document how to stream " Alberto Garcia
2015-04-15 16:25   ` [Qemu-devel] [Qemu-block] " Max Reitz
2015-04-15 16:27 ` [Qemu-devel] [Qemu-block] [PATCH v3 0/6] Support streaming " Max Reitz

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=552E8D2E.8060103@redhat.com \
    --to=mreitz@redhat.com \
    --cc=berto@igalia.com \
    --cc=qemu-block@nongnu.org \
    --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 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).