Re: [Qemu-devel] [PATCH v9] spec: add qcow2 bitmaps extension specification

[Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>]

On 04.02.2016 05:25, Fam Zheng wrote:
> On Wed, 02/03 20:16, Vladimir Sementsov-Ogievskiy wrote:
>> On 03.02.2016 17:41, Fam Zheng wrote:
>>> On Wed, 02/03 16:45, Vladimir Sementsov-Ogievskiy wrote:
>>>> Also current scheme is made like one for snapshots.
>>> Okay, then I'll be fine with being consistent.
>>>
>>>
>>>>>> +
>>>>>> +
>>>>>> +=== Bitmap table ===
>>>>>> +
>>>>>> +Bitmaps are stored using a one-level structure (as opposed to two-level
>>>>>> +structure like for refcounts and guest clusters mapping) for the mapping of
>>>>> s/structure/structures/
>>>>>
>>>>>> +bitmap data to host clusters. This structure is called the bitmap table.
>>>>>> +
>>>>>> +Each bitmap table has a variable size (stored in the bitmap directory entry)
>>>>>> +and may use multiple clusters, however, it must be contiguous in the image
>>>>>> +file.
>>>>>> +
>>>>>> +Structure of a bitmap table entry:
>>>>>> +
>>>>>> +    Bit       0:    Reserved and must be zero if bits 9 - 55 are non-zero.
>>>>>> +                    If bits 9 - 55 are zero:
>>>>>> +                      0: Cluster should be read as all zeros.
>>>>>> +                      1: Cluster should be read as all ones.
>>>>> Once bits 9 - 55 are non-zero, this bit goes useless? That doesn't make much
>>>>> sense to me. In which case bit 0 is set but 9-55 are zero?
>>>> In case "1: Cluster should be read as all ones.".
>>> I cannot think of a use case leading to this.
>> Why not? It is the dirty bitmap. It may be very dirty, it even may
>> be all-ones.
> I see what this is about. This assumes the bitmap is only saved when the image
> is closed, so that if by that time the whole chunk is all-one, this bit is set
> without allocating the cluster.
>
> But again, I don't think that is the only way to save bitmap: an implementation
> can save dirty bit much more frequently (to free memory), or even do it
> synchronously (to be power failure proof). In these cases, this bit is hard to
> use, because it's very unlikely all bits are dirtied between two adjacent
> saving points.
>
> Sorry for asking for this so late, what about making bit 0 and the offset
> orthogonal?
>
>                          Bits[9..55] = 0     |     Bits[9..55] != 0
>          Bit[0] = 0          zero            |         read
>          Bit[0] = 1          one             |         one

And what the meaning of bits[9..55] in case of bit[0] = 1? "Reserved" is 
better here, I think, than "ignored". In other places of this doc we 
switched from "ignored" to "reserved" during this discussion.

For example in case of snapshot-switch we will (may be) set all bits in 
the bitmap. Frequency of sync doesn't matter, the bitmaps becomes more 
and more dirty and it will be cleared only after next incremental backup.
"this bit is hard to use" - even if it is hard, you are not forced to 
use it: you can allocate cluster and set all bits in it (or unset them) 
and leave bit[0] = zero. It is an additional feature, which will save 
disk space and io in some cases.

>
> Fam


-- 
Best regards,
Vladimir