All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: Eric Blake <eblake@redhat.com>, qemu-devel@nongnu.org
Cc: david.edmondson@oracle.com, Kevin Wolf <kwolf@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	qemu-block@nongnu.org, mreitz@redhat.com
Subject: Re: [PATCH 13/17] qcow2: Add new autoclear feature for all zero image
Date: Mon, 3 Feb 2020 20:45:10 +0300	[thread overview]
Message-ID: <da530661-a976-35ca-d999-646074b72490@virtuozzo.com> (raw)
In-Reply-To: <20200131174436.2961874-14-eblake@redhat.com>

31.01.2020 20:44, Eric Blake wrote:
> With the recent introduction of BDRV_ZERO_OPEN, we can optimize
> various qemu-img operations if we know the destination starts life
> with all zero content.  For an image with no cluster allocations and
> no backing file, this was already trivial with BDRV_ZERO_CREATE; but
> for a fully preallocated image, it does not scale to crawl through the
> entire L1/L2 tree to see if every cluster is currently marked as a
> zero cluster.  But it is quite easy to add an autoclear bit to the
> qcow2 file itself: the bit will be set after newly creating an image
> or after qcow2_make_empty, and cleared on any other modification
> (including by an older qemu that doesn't recognize the bit).
> 
> This patch documents the new bit, independently of implementing the
> places in code that should set it (which means that for bisection
> purposes, it is safer to still mask the bit out when opening an image
> with the bit set).
> 
> A few iotests have updated output due to the larger number of named
> header features.
> 
> Signed-off-by: Eric Blake <eblake@redhat.com>
> 
> ---
> RFC: As defined in this patch, I defined the bit to be clear if any
> cluster defers to a backing file. But the block layer would handle
> things just fine if we instead allowed the bit to be set if all
> clusters allocated in this image are zero, even if there are other
> clusters not allocated.  Or maybe we want TWO bits: one if all
> clusters allocated here are known zero, and a second if we know that
> there are any clusters that defer to a backing image.
> ---
>   block/qcow2.c              |  9 +++++++++
>   block/qcow2.h              |  3 +++
>   docs/interop/qcow2.txt     | 12 +++++++++++-
>   qapi/block-core.json       |  4 ++++
>   tests/qemu-iotests/031.out |  8 ++++----
>   tests/qemu-iotests/036.out |  4 ++--
>   tests/qemu-iotests/061.out | 14 +++++++-------
>   7 files changed, 40 insertions(+), 14 deletions(-)
> 
> diff --git a/block/qcow2.c b/block/qcow2.c
> index 9f2371925737..20cce9410c84 100644
> --- a/block/qcow2.c
> +++ b/block/qcow2.c
> @@ -2859,6 +2859,11 @@ int qcow2_update_header(BlockDriverState *bs)
>                   .bit  = QCOW2_AUTOCLEAR_DATA_FILE_RAW_BITNR,
>                   .name = "raw external data",
>               },
> +            {
> +                .type = QCOW2_FEAT_TYPE_AUTOCLEAR,
> +                .bit  = QCOW2_AUTOCLEAR_ALL_ZERO_BITNR,
> +                .name = "all zero",
> +            },
>           };
> 
>           ret = header_ext_add(buf, QCOW2_EXT_MAGIC_FEATURE_TABLE,
> @@ -4874,6 +4879,10 @@ static ImageInfoSpecific *qcow2_get_specific_info(BlockDriverState *bs,
>               .corrupt            = s->incompatible_features &
>                                     QCOW2_INCOMPAT_CORRUPT,
>               .has_corrupt        = true,
> +            .all_zero           = s->autoclear_features &
> +                                  QCOW2_AUTOCLEAR_ALL_ZERO,
> +            .has_all_zero       = s->autoclear_features &
> +                                  QCOW2_AUTOCLEAR_ALL_ZERO,
>               .refcount_bits      = s->refcount_bits,
>               .has_bitmaps        = !!bitmaps,
>               .bitmaps            = bitmaps,
> diff --git a/block/qcow2.h b/block/qcow2.h
> index 094212623257..6fc2d323d753 100644
> --- a/block/qcow2.h
> +++ b/block/qcow2.h
> @@ -237,11 +237,14 @@ enum {
>   enum {
>       QCOW2_AUTOCLEAR_BITMAPS_BITNR       = 0,
>       QCOW2_AUTOCLEAR_DATA_FILE_RAW_BITNR = 1,
> +    QCOW2_AUTOCLEAR_ALL_ZERO_BITNR      = 2,
>       QCOW2_AUTOCLEAR_BITMAPS             = 1 << QCOW2_AUTOCLEAR_BITMAPS_BITNR,
>       QCOW2_AUTOCLEAR_DATA_FILE_RAW       = 1 << QCOW2_AUTOCLEAR_DATA_FILE_RAW_BITNR,
> +    QCOW2_AUTOCLEAR_ALL_ZERO            = 1 << QCOW2_AUTOCLEAR_ALL_ZERO_BITNR,
> 
>       QCOW2_AUTOCLEAR_MASK                = QCOW2_AUTOCLEAR_BITMAPS
>                                           | QCOW2_AUTOCLEAR_DATA_FILE_RAW,
> +    /* TODO: Add _ALL_ZERO to _MASK once it is handled correctly */
>   };
> 
>   enum qcow2_discard_type {
> diff --git a/docs/interop/qcow2.txt b/docs/interop/qcow2.txt
> index 8510d74c8079..d435363a413c 100644
> --- a/docs/interop/qcow2.txt
> +++ b/docs/interop/qcow2.txt
> @@ -153,7 +153,17 @@ in the description of a field.
>                                   File bit (incompatible feature bit 1) is also
>                                   set.
> 
> -                    Bits 2-63:  Reserved (set to 0)
> +                    Bit 2:      All zero image bit
> +                                If this bit is set, the entire image reads
> +                                as all zeroes. This can be useful for
> +                                detecting just-created images even when
> +                                clusters are preallocated, which in turn
> +                                can be used to optimize image copying.
> +
> +                                This bit should not be set if any cluster
> +                                in the image defers to a backing file.

Hmm. The term "defers to a backing file" not defined in the spec. And, as I
understand, can't be defined by design. Backing file may be added/removed/changed
dynamically, and qcow2 driver will not know about it. So, the only way to
be sure that clusters are not defer to backing file is to make them
ZERO clusters (not UNALLOCATED). But this is inefficient, as we'll have to
allocated all L2 tables.

So, I think better to define this flag as "all allocated clusters are zero".

Hmm interesting, in qcow2 spec "allocated" means allocated on disk and has
offset. So, ZERO cluster is actually unallocated cluster, with bit 0 of
L2 entry set to 1. On the other hand, qemu block layer considers ZERO
clusters as "allocated" (in POV of backing-chain).

So, if we define it as "all allocated clusters are zero", we are done:
other clusters are either unallocated and MAY refer to backing, so we
can say nothing about their read-as-zero status at the level of qcow2
spec, or unallocated with zero-bit set, which are normal ZERO clusters.

So, on the level of qcow2 driver I think it's better consider only this
image. Still, we can implement generic bdrv_is_all_zeros, which will
check or layers (or at least, check that bs->backing is NULL).


> +
> +                    Bits 3-63:  Reserved (set to 0)
> 
>            96 -  99:  refcount_order
>                       Describes the width of a reference count block entry (width
> diff --git a/qapi/block-core.json b/qapi/block-core.json
> index ef94a296868f..af837ed5af33 100644
> --- a/qapi/block-core.json
> +++ b/qapi/block-core.json
> @@ -71,6 +71,9 @@
>   # @corrupt: true if the image has been marked corrupt; only valid for
>   #           compat >= 1.1 (since 2.2)
>   #
> +# @all-zero: present and true only if the image is known to read as all
> +#            zeroes (since 5.0)
> +#
>   # @refcount-bits: width of a refcount entry in bits (since 2.3)
>   #
>   # @encrypt: details about encryption parameters; only set if image
> @@ -87,6 +90,7 @@
>         '*data-file-raw': 'bool',
>         '*lazy-refcounts': 'bool',
>         '*corrupt': 'bool',
> +      '*all-zero': 'bool',
>         'refcount-bits': 'int',
>         '*encrypt': 'ImageInfoSpecificQCow2Encryption',
>         '*bitmaps': ['Qcow2BitmapInfo']
> diff --git a/tests/qemu-iotests/031.out b/tests/qemu-iotests/031.out
> index 46f97c5a4ea4..bb1afa7b87f6 100644
> --- a/tests/qemu-iotests/031.out
> +++ b/tests/qemu-iotests/031.out
> @@ -117,7 +117,7 @@ header_length             104
> 
>   Header extension:
>   magic                     0x6803f857
> -length                    288
> +length                    336
>   data                      <binary>
> 
>   Header extension:
> @@ -150,7 +150,7 @@ header_length             104
> 
>   Header extension:
>   magic                     0x6803f857
> -length                    288
> +length                    336
>   data                      <binary>
> 
>   Header extension:
> @@ -164,7 +164,7 @@ No errors were found on the image.
> 
>   magic                     0x514649fb
>   version                   3
> -backing_file_offset       0x1d8
> +backing_file_offset       0x208
>   backing_file_size         0x17
>   cluster_bits              16
>   size                      67108864
> @@ -188,7 +188,7 @@ data                      'host_device'
> 
>   Header extension:
>   magic                     0x6803f857
> -length                    288
> +length                    336
>   data                      <binary>
> 
>   Header extension:
> diff --git a/tests/qemu-iotests/036.out b/tests/qemu-iotests/036.out
> index 23b699ce0622..e409acf60e2b 100644
> --- a/tests/qemu-iotests/036.out
> +++ b/tests/qemu-iotests/036.out
> @@ -26,7 +26,7 @@ compatible_features       []
>   autoclear_features        [63]
>   Header extension:
>   magic                     0x6803f857
> -length                    288
> +length                    336
>   data                      <binary>
> 
> 
> @@ -38,7 +38,7 @@ compatible_features       []
>   autoclear_features        []
>   Header extension:
>   magic                     0x6803f857
> -length                    288
> +length                    336
>   data                      <binary>
> 
>   *** done
> diff --git a/tests/qemu-iotests/061.out b/tests/qemu-iotests/061.out
> index 413cc4e0f4ab..d873f79bb606 100644
> --- a/tests/qemu-iotests/061.out
> +++ b/tests/qemu-iotests/061.out
> @@ -26,7 +26,7 @@ header_length             104
> 
>   Header extension:
>   magic                     0x6803f857
> -length                    288
> +length                    336
>   data                      <binary>
> 
>   magic                     0x514649fb
> @@ -84,7 +84,7 @@ header_length             104
> 
>   Header extension:
>   magic                     0x6803f857
> -length                    288
> +length                    336
>   data                      <binary>
> 
>   magic                     0x514649fb
> @@ -140,7 +140,7 @@ header_length             104
> 
>   Header extension:
>   magic                     0x6803f857
> -length                    288
> +length                    336
>   data                      <binary>
> 
>   ERROR cluster 5 refcount=0 reference=1
> @@ -195,7 +195,7 @@ header_length             104
> 
>   Header extension:
>   magic                     0x6803f857
> -length                    288
> +length                    336
>   data                      <binary>
> 
>   magic                     0x514649fb
> @@ -264,7 +264,7 @@ header_length             104
> 
>   Header extension:
>   magic                     0x6803f857
> -length                    288
> +length                    336
>   data                      <binary>
> 
>   read 65536/65536 bytes at offset 44040192
> @@ -298,7 +298,7 @@ header_length             104
> 
>   Header extension:
>   magic                     0x6803f857
> -length                    288
> +length                    336
>   data                      <binary>
> 
>   ERROR cluster 5 refcount=0 reference=1
> @@ -327,7 +327,7 @@ header_length             104
> 
>   Header extension:
>   magic                     0x6803f857
> -length                    288
> +length                    336
>   data                      <binary>
> 
>   read 131072/131072 bytes at offset 0
> 


-- 
Best regards,
Vladimir


  reply	other threads:[~2020-02-03 17:46 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-31 17:44 [PATCH 00/17] Improve qcow2 all-zero detection Eric Blake
2020-01-31 17:44 ` [PATCH 01/17] qcow2: Comment typo fixes Eric Blake
2020-02-04 14:12   ` Vladimir Sementsov-Ogievskiy
2020-02-09 19:34   ` Alberto Garcia
2020-01-31 17:44 ` [PATCH 02/17] qcow2: List autoclear bit names in header Eric Blake
2020-02-04 14:26   ` Vladimir Sementsov-Ogievskiy
2020-01-31 17:44 ` [PATCH 03/17] qcow2: Avoid feature name extension on small cluster size Eric Blake
2020-02-04 14:39   ` Vladimir Sementsov-Ogievskiy
2020-02-09 19:28   ` Alberto Garcia
2020-01-31 17:44 ` [PATCH 04/17] block: Improve documentation of .bdrv_has_zero_init Eric Blake
2020-02-04 15:03   ` Vladimir Sementsov-Ogievskiy
2020-02-04 15:16     ` Eric Blake
2020-01-31 17:44 ` [PATCH 05/17] block: Don't advertise zero_init_truncate with encryption Eric Blake
2020-02-10 18:12   ` Alberto Garcia
2020-01-31 17:44 ` [PATCH 06/17] block: Improve bdrv_has_zero_init_truncate with backing file Eric Blake
2020-02-10 18:13   ` Alberto Garcia
2020-01-31 17:44 ` [PATCH 07/17] gluster: Drop useless has_zero_init callback Eric Blake
2020-02-04 15:06   ` Vladimir Sementsov-Ogievskiy
2020-02-10 18:21   ` Alberto Garcia
2020-02-17  8:06   ` [GEDI] " Niels de Vos
2020-02-17 12:03     ` Eric Blake
2020-02-17 12:22       ` Eric Blake
2020-02-17 14:01       ` Niels de Vos
2020-01-31 17:44 ` [PATCH 08/17] sheepdog: Consistently set bdrv_has_zero_init_truncate Eric Blake
2020-02-04 15:09   ` Vladimir Sementsov-Ogievskiy
2020-01-31 17:44 ` [PATCH 09/17] block: Refactor bdrv_has_zero_init{,_truncate} Eric Blake
2020-02-04 15:35   ` Vladimir Sementsov-Ogievskiy
2020-02-04 15:49     ` Eric Blake
2020-02-04 16:07       ` Vladimir Sementsov-Ogievskiy
2020-02-04 17:42     ` Max Reitz
2020-02-04 17:51       ` Eric Blake
2020-02-05 16:43         ` Max Reitz
2020-02-05  7:51       ` Vladimir Sementsov-Ogievskiy
2020-02-05 14:07         ` Eric Blake
2020-02-05 14:25           ` Vladimir Sementsov-Ogievskiy
2020-02-05 14:36             ` Eric Blake
2020-02-05 17:55           ` Max Reitz
2020-02-04 17:53   ` Max Reitz
2020-02-04 19:03     ` Eric Blake
2020-02-05 17:22       ` Max Reitz
2020-02-05 18:39         ` Eric Blake
2020-02-06  9:18           ` Max Reitz
2020-01-31 17:44 ` [PATCH 10/17] block: Add new BDRV_ZERO_OPEN flag Eric Blake
2020-01-31 18:03   ` Eric Blake
2020-02-04 17:34   ` Max Reitz
2020-02-04 17:50     ` Eric Blake
2020-02-05  8:39       ` Vladimir Sementsov-Ogievskiy
2020-02-05 17:26       ` Max Reitz
2020-01-31 17:44 ` [PATCH 11/17] file-posix: Support BDRV_ZERO_OPEN Eric Blake
2020-01-31 17:44 ` [PATCH 12/17] gluster: " Eric Blake
2020-02-17  8:16   ` [GEDI] " Niels de Vos
2020-01-31 17:44 ` [PATCH 13/17] qcow2: Add new autoclear feature for all zero image Eric Blake
2020-02-03 17:45   ` Vladimir Sementsov-Ogievskiy [this message]
2020-02-04 13:12     ` Eric Blake
2020-02-04 13:29       ` Vladimir Sementsov-Ogievskiy
2020-01-31 17:44 ` [PATCH 14/17] qcow2: Expose all zero bit through .bdrv_known_zeroes Eric Blake
2020-01-31 17:44 ` [PATCH 15/17] qcow2: Implement all-zero autoclear bit Eric Blake
2020-01-31 17:44 ` [PATCH 16/17] iotests: Add new test for qcow2 all-zero bit Eric Blake
2020-01-31 17:44 ` [PATCH 17/17] qcow2: Let qemu-img check cover " Eric Blake
2020-02-04 17:32 ` [PATCH 00/17] Improve qcow2 all-zero detection Max Reitz
2020-02-04 18:53   ` Eric Blake
2020-02-05 17:04     ` Max Reitz
2020-02-05 19:21       ` Eric Blake
2020-02-06  9:12         ` Max Reitz
2020-02-05  9:04 ` Vladimir Sementsov-Ogievskiy
2020-02-05  9:25   ` Vladimir Sementsov-Ogievskiy
2020-02-05 14:26     ` Eric Blake
2020-02-05 14:47       ` Vladimir Sementsov-Ogievskiy
2020-02-05 15:14         ` Vladimir Sementsov-Ogievskiy
2020-02-05 17:58           ` Max Reitz
2020-02-05 14:22   ` Eric Blake
2020-02-05 14:43     ` Vladimir Sementsov-Ogievskiy
2020-02-05 14:58       ` Vladimir Sementsov-Ogievskiy

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=da530661-a976-35ca-d999-646074b72490@virtuozzo.com \
    --to=vsementsov@virtuozzo.com \
    --cc=armbru@redhat.com \
    --cc=david.edmondson@oracle.com \
    --cc=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --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 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.