qemu-devel
[Top][All Lists]
Advanced

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

Re: [RFC PATCH v3 05/27] qcow2: Document the Extended L2 Entries feature


From: Alberto Garcia
Subject: Re: [RFC PATCH v3 05/27] qcow2: Document the Extended L2 Entries feature
Date: Thu, 20 Feb 2020 15:49:52 +0100
User-agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (i586-pc-linux-gnu)

On Thu 20 Feb 2020 03:28:17 PM CET, Eric Blake wrote:
>> +An image uses Extended L2 Entries if bit 3 is set on the 
>> incompatible_features
>> +field of the header.
>> +
>> +In these images standard data clusters are divided into 32 subclusters of 
>> the
>> +same size. They are contiguous and start from the beginning of the cluster.
>> +Subclusters can be allocated independently and the L2 entry contains 
>> information
>> +indicating the status of each one of them. Compressed data clusters don't 
>> have
>> +subclusters so they are treated like in images without this feature.
>
> Grammar; I'd suggest:
>
> ...don't have subclusters, so they are treated the same as in images 
> without this feature.

Ok

> Are they truly the same, or do you still need to document that the
> extra 64 bits of the extended L2 entry are all zero?

It is documented later in the same patch ("Subcluster Allocation Bitmap
for compressed clusters").

By the way, this series treats an L2 entry as invalid if any of those
bits is not zero, but I think I'll change that. Conceivably those bits
could be used for a future compatible feature, but it can only be
compatible if the previous versions ignore those bits.

>> +        32 -  63    Subcluster reads as zeros (one bit per subcluster)
>> +
>> +                    1: the subcluster reads as zeros. In this case the
>> +                       allocation status bit must be unset. The host
>> +                       cluster offset field may or may not be set.
>
> Why must the allocation bit be unset?  When we preallocate, we want a
> cluster to reserve space, but still read as zero, so the combination
> of both bits set makes sense to me.

Since 00 means unallocated and 01 allocated, there are two options left
to represent the "reads as zero" case: 10 and 11.

I think that one could argue for either one and there is no "right"
choice. I chose the former because I understood the allocation bit as
"the guest visible data is obtained from the raw data in that
subcluster" but the other option also makes sense.

Berto



reply via email to

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