[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH v2 1/3] qcow2: introduce compression type featur

From: Max Reitz
Subject: Re: [Qemu-block] [PATCH v2 1/3] qcow2: introduce compression type feature
Date: Thu, 8 Aug 2019 14:50:29 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

On 08.08.19 02:18, Eric Blake wrote:
> On 7/4/19 8:09 AM, Denis Plotnikov wrote:
>> The patch adds some preparation parts for incompatible compression type
>> feature to QCOW2 header that indicates that *all* compressed clusters
>> must be (de)compressed using a certain compression type.
>> It is implied that the compression type is set on the image creation and
>> can be changed only later by image conversion, thus compression type
>> defines the only compression algorithm used for the image.
>> The goal of the feature is to add support of other compression algorithms
>> to qcow2. For example, ZSTD which is more effective on compression than ZLIB.
>> It works roughly 2x faster than ZLIB providing a comparable compression ratio
>> and therefore provide a performance advantage in backup scenarios.
> provides
>> The default compression is ZLIB. Images created with ZLIB compression type
>> are backward compatible with older qemu versions.
>> Signed-off-by: Denis Plotnikov <address@hidden>
>> +++ b/docs/interop/qcow2.txt
>> @@ -109,7 +109,12 @@ in the description of a field.
>>                                  An External Data File Name header extension 
>> may
>>                                  be present if this bit is set.
>> -                    Bits 3-63:  Reserved (set to 0)
>> +                    Bit 3:      Compression type bit. The bit must be set if
>> +                                the compression type differs from default: 
>> zlib.
> I'd word this 'from the default of zlib.'
>> +                                If the compression type is default the bit 
>> must
>> +                                be unset.
> Why? I see no reason to forbid a qcow2 image that has the incompatible
> bit set but still uses zlib compression.  True, such an image is not as
> friendly to older clients, but it is not technically wrong, and newer
> clients would still be able to use the image if not for this sentence
> telling them they must not.

Just because an image doesn’t adhere to the specification doesn’t mean
you have to reject it, if the intention is clear.

> I'd drop this sentence.

I wouldn’t, I like it (in essence).  Though maybe the “must” is indeed
too strong and it should be a “should” instead.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]