Re: [Qemu-devel] [PATCH for-2.10 v2] block: Skip implicit nodes in query-block/blockstats

[Peter Krempa <pkrempa@redhat.com>]

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

On Wed, Jul 19, 2017 at 15:58:05 +0200, Kevin Wolf wrote:
> Commits 0db832f and 6cdbceb introduced the automatic insertion of filter
> nodes above the top layer of mirror and commit block jobs. The
> assumption made there was that since libvirt doesn't do node-level
> management of the block layer yet, it shouldn't be affected by added
> nodes.
> 
> This is true as far as commands issued by libvirt are concerned. It only
> uses BlockBackend names to address nodes, so any operations it performs
> still operate on the root of the tree as intended.
> 
> However, the assumption breaks down when you consider query commands,
> which return data for the wrong node now. These commands also return
> information on some child nodes (bs->file and/or bs->backing), which
> libvirt does make use of, and which refer to the wrong nodes, too.
> 
> One of the consequences is that oVirt gets wrong information about the
> image size and stops the VM in response as long as a mirror or commit
> job is running:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1470634
> 
> This patch fixes the problem by hiding the implicit nodes created
> automatically by the mirror and commit block jobs in the output of
> query-block and BlockBackend-based query-blockstats as long as the user
> doesn't indicate that they are aware of those nodes by providing a node
> name for them in the QMP command to start the block job.
> 
> The node-based commands query-named-block-nodes and query-blockstats
> with query-nodes=true still show all nodes, including implicit ones.
> This ensures that users that are capable of node-level management can
> still access the full information; users that only know BlockBackends
> won't use these commands.
> 
> Cc: qemu-stable@nongnu.org
> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> ---
> 
> v2:
> - Skip implicit nodes not only on the top level, but also during the recursive
>   calls [Peter]
> - Spelling fix in the commit message [Manos]
> 
>  block/commit.c             |  3 +++
>  block/mirror.c             |  3 +++
>  block/qapi.c               | 30 +++++++++++++++++++++++++-----
>  include/block/block_int.h  |  1 +
>  qapi/block-core.json       |  6 ++++--
>  tests/qemu-iotests/041     | 23 +++++++++++++++++++++++
>  tests/qemu-iotests/041.out |  4 ++--
>  7 files changed, 61 insertions(+), 9 deletions(-)
> 

[...]

> diff --git a/block/qapi.c b/block/qapi.c
> index 95b2e2d..d370d0f 100644
> --- a/block/qapi.c
> +++ b/block/qapi.c
> @@ -133,6 +133,13 @@ BlockDeviceInfo *bdrv_block_device_info(BlockBackend *blk,
>              qapi_free_BlockDeviceInfo(info);
>              return NULL;
>          }
> +
> +        /* Skip automatically inserted nodes that the user isn't aware of for
> +         * query-block (blk != NULL), but not for query-named-block-nodes */
> +        while (blk && bs0 && bs0->drv && bs0->implicit) {
> +            bs0 = backing_bs(bs0);
> +        }

I don't think that the ordering of this part is correct.

This checks that the current bds in 'bs0' is not an 'implicit' node
, and if not ...

> +
>          if (bs0->drv && bs0->backing) {
>              bs0 = bs0->backing->bs;

... this then fills bs0 with the backing file and in the next loop, the
first thing we do is to populate the data. At this point it's not
guaranteed though that the backing image is not a implicit node added
by a commit job.

I think you want to check if bs0 is implicit after you populate it by
the backing image pointer.

>              (*p_image_info)->has_backing_image = true;

[...]

> @@ -434,8 +446,8 @@ static void bdrv_query_blk_stats(BlockDeviceStats *ds, BlockBackend *blk)
>      }
>  }
>  
> -static BlockStats *bdrv_query_bds_stats(const BlockDriverState *bs,
> -                                 bool query_backing)
> +static BlockStats *bdrv_query_bds_stats(BlockDriverState *bs,
> +                                        bool blk_level)
>  {
>      BlockStats *s = NULL;
>  
> @@ -446,6 +458,14 @@ static BlockStats *bdrv_query_bds_stats(const BlockDriverState *bs,
>          return s;
>      }
>  
> +    /* Skip automatically inserted nodes that the user isn't aware of in
> +     * a BlockBackend-level command. Stay at the exact node for a node-level
> +     * command. */
> +    while (blk_level && bs->drv && bs->implicit) {
> +        bs = backing_bs(bs);
> +        assert(bs);
> +    }
> +
>      if (bdrv_get_node_name(bs)[0]) {
>          s->has_node_name = true;
>          s->node_name = g_strdup(bdrv_get_node_name(bs));


This is okay, but what puzzles me is that it looks like
bdrv_query_bds_stats recursively fills in the whole backing chain (but
does not really enter much stats, besides the highest offset and the
node name [1]).

But then in qmp_query_blockstats only the top layer is populated by
bdrv_query_blk_stats. I guess it makes some sense since not all stats
are available for the lower levels of backing chain, but I find it weird
that the whole nested structure full of empty fields is reported.

Peter

[1] The nested node name structure is great, since the current libvirt
node name detection code is very fragile. This will allow making it much
more robust. (the code is used to set the block write threshold event)

Obviously the plan is still to supply the node names explicitly.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]