qcow2: Correctly report status of preallocated zero clusters
authorEric Blake <eblake@redhat.com>
Sun, 7 May 2017 00:05:44 +0000 (19:05 -0500)
committerMax Reitz <mreitz@redhat.com>
Thu, 11 May 2017 12:28:06 +0000 (14:28 +0200)
commit4341df8a83d6a528a1e2855735f87fc3aab42b70
tree67a791ef02e3c7b1a7db01d3ac58d45a46aac800
parent4c41cb4955effff3447bd07a09e0af9c6e0453e3
qcow2: Correctly report status of preallocated zero clusters

We were throwing away the preallocation information associated with
zero clusters.  But we should be matching the well-defined semantics
in bdrv_get_block_status(), where (BDRV_BLOCK_ZERO |
BDRV_BLOCK_OFFSET_VALID) informs the user which offset is reserved,
while still reminding the user that reading from that offset is
likely to read garbage.

count_contiguous_clusters_by_type() is now used only for unallocated
cluster runs, hence it gets renamed and tightened.

Making this change lets us see which portions of an image are zero
but preallocated, when using qemu-img map --output=json.  The
--output=human side intentionally ignores all zero clusters, whether
or not they are preallocated.

The fact that there is no change to qemu-iotests './check -qcow2'
merely means that we aren't yet testing this aspect of qemu-img;
a later patch will add a test.

Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Message-id: 20170507000552.20847-5-eblake@redhat.com
Signed-off-by: Max Reitz <mreitz@redhat.com>
block/qcow2-cluster.c