I've collected several improvements for qcow2 zero-cluster handling.

Available as a tag at:
git fetch git://repo.or.cz/qemu/ericb.git nbd-blkdebug-v12

Marked as v12 for "hysterical raisins", since it it the half of
v10 [1] that was not resubmitted as v11 [2].

Depends on Max's block tree:
https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg00641.html
and on Max's qcow2 cleanups:
https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg00689.html

[1] https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg05227.html
[2] https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg05896.html

Changes since last posting:
- lots of tweaks to resolve Max's review findings, including
rewriting my additions to test 154
- a new patch splitting QCOW2_CLUSTER_ZERO that fell out from
my review of Max's work
- defer any optimizations of a backing file with different length
until later (I will still post an RFC patch to explore what
optimizations a BDRV_BLOCK_EOF would allow, but didn't want to
hold up this series any further)

001/10:[down] 'qcow2: Use consistent switch indentation'
002/10:[0043] [FC] 'block: Update comments on BDRV_BLOCK_* meanings'
003/10:[0023] [FC] 'qcow2: Correctly report status of preallocated zero clusters'
004/10:[down] 'qcow2: Make distinction between zero cluster types obvious'
005/10:[0008] [FC] 'qcow2: Optimize zero_single_l2() to minimize L2 churn'
006/10:[down] 'iotests: Improve _filter_qemu_img_map'
007/10:[0107] [FC] 'iotests: Add test 179 to cover write zeroes with unmap'
008/10:[0260] [FC] 'qcow2: Optimize write zero of unaligned tail cluster'
009/10:[----] [--] 'qcow2: Assert that cluster operations are aligned'
010/10:[0005] [FC] 'qcow2: Discard/zero clusters by byte count'

Eric Blake (10):
  qcow2: Use consistent switch indentation
  block: Update comments on BDRV_BLOCK_* meanings
  qcow2: Correctly report status of preallocated zero clusters
  qcow2: Make distinction between zero cluster types obvious
  qcow2: Optimize zero_single_l2() to minimize L2 churn
  iotests: Improve _filter_qemu_img_map
  iotests: Add test 179 to cover write zeroes with unmap
  qcow2: Optimize write zero of unaligned tail cluster
  qcow2: Assert that cluster operations are aligned
  qcow2: Discard/zero clusters by byte count

 block/qcow2.h                    |  17 +++--
 include/block/block.h            |  35 +++++----
 include/block/block_int.h        |   7 ++
 block/qcow2-cluster.c            | 156 ++++++++++++++++++++++----------------
 block/qcow2-refcount.c           | 124 +++++++++++++++---------------
 block/qcow2-snapshot.c           |   7 +-
 block/qcow2.c                    |  38 ++++++----
 tests/qemu-iotests/common.filter |   4 +-
 tests/qemu-iotests/122.out       |  16 ++--
 tests/qemu-iotests/154           | 160 ++++++++++++++++++++++++++++++++++++++-
 tests/qemu-iotests/154.out       | 159 ++++++++++++++++++++++++++++++++++----
 tests/qemu-iotests/179           | 132 ++++++++++++++++++++++++++++++++
 tests/qemu-iotests/179.out       | 160 +++++++++++++++++++++++++++++++++++++++
 tests/qemu-iotests/group         |   1 +
 14 files changed, 818 insertions(+), 198 deletions(-)
 create mode 100755 tests/qemu-iotests/179
 create mode 100644 tests/qemu-iotests/179.out

-- 
2.9.3

On 04.05.2017 05:07, Eric Blake wrote:
> I've collected several improvements for qcow2 zero-cluster handling.
> 
> Available as a tag at:
> git fetch git://repo.or.cz/qemu/ericb.git nbd-blkdebug-v12
> 
> Marked as v12 for "hysterical raisins", since it it the half of
> v10 [1] that was not resubmitted as v11 [2].
> 
> Depends on Max's block tree:
> https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg00641.html
> and on Max's qcow2 cleanups:
> https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg00689.html
> 
> [1] https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg05227.html
> [2] https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg05896.html
> 
> Changes since last posting:
> - lots of tweaks to resolve Max's review findings, including
> rewriting my additions to test 154
> - a new patch splitting QCOW2_CLUSTER_ZERO that fell out from
> my review of Max's work
> - defer any optimizations of a backing file with different length
> until later (I will still post an RFC patch to explore what
> optimizations a BDRV_BLOCK_EOF would allow, but didn't want to
> hold up this series any further)

I have given an R-b for every patch, so I could apply the series as-is
(with the really minor fixes we have talked about, and the thing in
patch 8), and I would be more or less OK with that. But I did have my
fair share of nit picks and before I discard all of them, I'd like to
know for sure that you don't intend to address them, or address them in
a follow-up.

I'm saying this because some of the issues I had do not really lend
themselves nicely to a follow-up; for instance the
s/Data cluster/Cluster allocation/ for patch 4.

From my perspective, it's not much more difficult to review a respin of
this series which just these minor points changed and maybe some very
small patches (the follow-up, basically) added to it.

Max

On 05/05/2017 05:18 PM, Max Reitz wrote:
> On 04.05.2017 05:07, Eric Blake wrote:
>> I've collected several improvements for qcow2 zero-cluster handling.
>>
>> Available as a tag at:
>> git fetch git://repo.or.cz/qemu/ericb.git nbd-blkdebug-v12
>>
>> Marked as v12 for "hysterical raisins", since it it the half of
>> v10 [1] that was not resubmitted as v11 [2].
>>
>> Depends on Max's block tree:
>> https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg00641.html
>> and on Max's qcow2 cleanups:
>> https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg00689.html
>>
>> [1] https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg05227.html
>> [2] https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg05896.html
>>

> I have given an R-b for every patch, so I could apply the series as-is
> (with the really minor fixes we have talked about, and the thing in
> patch 8), and I would be more or less OK with that. But I did have my
> fair share of nit picks and before I discard all of them, I'd like to
> know for sure that you don't intend to address them, or address them in
> a follow-up.
> 
> I'm saying this because some of the issues I had do not really lend
> themselves nicely to a follow-up; for instance the
> s/Data cluster/Cluster allocation/ for patch 4.
> 
> From my perspective, it's not much more difficult to review a respin of
> this series which just these minor points changed and maybe some very
> small patches (the follow-up, basically) added to it.

v13 coming soon to a list near you (but maybe not until Monday) - let's
see if it's the lucky one!

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org