Re: [Qemu-devel] [PATCH 03/17] spec: add qcow2-dirty-bitmaps specification

[Eric Blake]

On 10/06/2015 02:22 PM, John Snow wrote:


>>> +Dirty Bitmap Directory Entry:
>>> +

>>> +
>>> +        24 - 27:    flags
>>> +                    Bit
>>> +                      0: in_use
>>> +                         The bitmap is in use and may be inconsistent.
>>> +
>>> +                      1: self
>>> +                         The bitmap is a dirty bitmap for the
>>> containing image.
>>> +
>>> +                      2: auto
>>> +                         The bitmap should be autoloaded as block
>>> dirty bitmap.
>>> +                         Only available if bit 1 (self) is set.
>>> +
>>> +                      3: read_only
>>> +                         The bitmap should not be rewritten.
>>> +
>>> +                    Bits 4 - 31 are reserved.
>>
>> Is this appropriate as field, reserved for future extensiion? Or we need
>> an additional one? Do we need scheme like with snapshots? (somthing like
>> field 'additional_area_size', and additional offset of this size after
>> the name)
>>
> 
> I think it would remain appropriate as long as we have a version header
> for the bitmap extension as a whole.

Simply requiring that the bits must be 0 is good enough for now.

> 
> e.g. "Bits 4 - 31 are reserved in qcow2.bitmap.v1 ..."
> 
> If a program that only knows about v1 opens a v2 file and find it
> conforms to spec (does not use the new reserved bits), then it can
> continue along happily.

I don't know that you even have to mention versions of the header, so
much as the blanket statement that any set bit not described by this
version of the spec is either a data corruption or evidence of a newer
version of the spec having edited the file in the meantime.  It works as
long as you require conforming clients to set reserved bits to 0.

> 
> If a reserved bit is set, it's an error and the v1 program must not
> alter the image in case it ruins the consistency of the file.
> 
> The usual suspects (Kevin, Markus, Stefan and Eric) may have better
> suggestions for how to handle future compatibility by drawing upon their
> experience with qcow2.

No, I think we're just fine. If any future spec version requires
additional space, then it can use one of the bits 4-31 as a flag to call
out that space, and older clients will handily refuse to operate on the
file without having to know that the bit meant that the header occupied
more space in the newer version of the spec.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature