Re: ImageInfo oddities regarding compression

[Eric Blake]

On 11/27/20 4:32 AM, Kevin Wolf wrote:

>>>    ##
>>>    # @Qcow2CompressionType:
>>>    #
>>>    # Compression type used in qcow2 image file
>>>    #
>>>    # @zlib: zlib compression, see <http://zlib.net/>
>>>    # @zstd: zstd compression, see <http://github.com/facebook/zstd>
>>>    #
>>>    # Since: 5.1
>>>    ##
>>>    { 'enum': 'Qcow2CompressionType',
>>>      'data': [ 'zlib', { 'name': 'zstd', 'if': 'defined(CONFIG_ZSTD)' } ] }
>>>
>>> Apparently, you can't have a qcow2 image without compression.  Correct?
>>>
>>> Can you imagine a use case for "without compression"?
>>
>> Yes & no. An image always has a compression type, either implicitly
>> zlib as the historical default, or explicitly as a type recorded in
>> the header.  This doesn't mean compression is used.
>>
>> There may be zero or more clusters actually using compression.
>> Typically compression will never be used, but there's still an
>> associated compression type regardless.
> 
> Right, so the correct answer to "is this image compressed?" is "unknown"
> for qcow2. Providing an answer would require checking all clusters in
> the image for the compression flag, which is not something we want to do
> for query-block. And even if we did that, it would still be unclear what
> to do with a partially compressed image.

If we truly need it, we could define three new autoclear bits in the
qcow2 spec:

bit 2: set if bits 3-4 are known to describe entire image
bit 3: set any time a compressed cluster is written to the image
bit 4: set any time an uncompressed cluster is written to the image

Any edit to the image by an older qemu will clear all three bits,
whereas new qemu would set bit 2 on image creation, and set the
appropriate bit 3 or 4 on any cluster write, so that we then have the
following knowledge:

234
===
000 - image was created or modified by older qemu; we have no idea if
clusters are written, or if compression was used, without expensive scan
001 - image contains at least one normal cluster, but no idea if it also
contains compressed clusters without expensive scan
010 - image contains at least one compressed cluster, but no idea if it
is fully compressed without expensive scan
011 - image contains mix of normal and compressed clusters
100 - image is newly created with no written clusters
101 - image contains only normal clusters; compression type could be
changed without risk
110 - image contains only compressed clusters
111 - image contains mix of normal and compressed clusters

But I'm not sure we need it.

> 
> The @compression-type only tells you what format a compressed cluster
> uses if any compressed cluster exists in the image (or if a new
> compressed cluster is written to it). It doesn't mean that such clusters
> currently exist.
> 
> Kevin
> 
> 

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