qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Hanna Czenczek <hreitz@redhat.com>
To: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>, qemu-block@nongnu.org
Cc: qemu-devel@nongnu.org, kwolf@redhat.com, fam@euphon.net,
	eblake@redhat.com, vsementsov@yandex-team.ru, den@virtuozzo.com
Subject: Re: [PATCH v2 2/3] qemu-img: map: report compressed data blocks
Date: Fri, 25 Aug 2023 16:14:05 +0200	[thread overview]
Message-ID: <ada340d8-8ac1-9817-6d58-0da60a601637@redhat.com> (raw)
In-Reply-To: <20230706163047.128999-3-andrey.drobyshev@virtuozzo.com>

On 06.07.23 18:30, Andrey Drobyshev wrote:
> Right now "qemu-img map" reports compressed blocks as containing data
> but having no host offset.  This is not very informative.  Instead,
> let's add another boolean field named "compressed" in case JSON output
> mode is specified.  This is achieved by utilizing new allocation status
> flag BDRV_BLOCK_COMPRESSED for bdrv_block_status().
>
> Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
> ---
>   qapi/block-core.json |  7 +++++--
>   qemu-img.c           | 16 +++++++++++++---
>   2 files changed, 18 insertions(+), 5 deletions(-)

Patch 3 must be merged into this patch.  Every test must pass on every 
commit so we don’t break bisecting.

> diff --git a/qapi/block-core.json b/qapi/block-core.json
> index 5dd5f7e4b0..b263d2cd30 100644
> --- a/qapi/block-core.json
> +++ b/qapi/block-core.json
> @@ -409,6 +409,9 @@
>   #
>   # @zero: whether the virtual blocks read as zeroes
>   #
> +# @compressed: true indicates that data is stored compressed.  Optional,
> +#     only valid for the formats whith support compression

This is missing information for when this field was introduced (i.e. a 
“(since 8.2)”).

I also wonder why this field is optional.  We have compression 
information even for formats that don’t support compression, 
specifically, nothing is compressed.  I would just make this field 
mandatory and print it always.  (A technical reason to do so is that 
this patch uses block_driver_can_compress() to figure out whether there 
is compression support; but that function only tells whether the driver 
can write compressed data.  Even if it cannot do that, the format may 
still support compression, and the driver may be able to read compressed 
data, just not write it.)

Hanna

> +#
>   # @depth: number of layers (0 = top image, 1 = top image's backing
>   #     file, ..., n - 1 = bottom image (where n is the number of images
>   #     in the chain)) before reaching one for which the range is
> @@ -426,8 +429,8 @@



  parent reply	other threads:[~2023-08-25 14:14 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-06 16:30 [PATCH v2 0/3] qemu-img: map: implement support for compressed clusters Andrey Drobyshev via
2023-07-06 16:30 ` [PATCH v2 1/3] block: add BDRV_BLOCK_COMPRESSED flag for bdrv_block_status() Andrey Drobyshev via
2023-07-12  7:13   ` Denis V. Lunev
2023-08-25 14:14   ` Hanna Czenczek
2023-07-06 16:30 ` [PATCH v2 2/3] qemu-img: map: report compressed data blocks Andrey Drobyshev via
2023-07-12  7:14   ` Denis V. Lunev
2023-08-25 14:14   ` Hanna Czenczek [this message]
2023-08-29  6:44     ` Andrey Drobyshev
2023-08-29  8:46       ` Hanna Czenczek
2023-07-06 16:30 ` [PATCH v2 3/3] qemu-iotests: update expected tests output to contain "compressed" field Andrey Drobyshev via
2023-07-12  7:14   ` Denis V. Lunev
2023-07-24 13:10 ` [PATCH v2 0/3] qemu-img: map: implement support for compressed clusters Andrey Drobyshev
2023-07-31 14:45   ` Andrey Drobyshev
2023-08-16  9:22     ` Andrey Drobyshev
2023-08-22 17:35       ` Andrey Drobyshev

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=ada340d8-8ac1-9817-6d58-0da60a601637@redhat.com \
    --to=hreitz@redhat.com \
    --cc=andrey.drobyshev@virtuozzo.com \
    --cc=den@virtuozzo.com \
    --cc=eblake@redhat.com \
    --cc=fam@euphon.net \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=vsementsov@yandex-team.ru \
    /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).