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

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

On 19.01.2016 20:27, Kevin Wolf wrote:
> Am 18.01.2016 um 22:16 hat Eric Blake geschrieben:
>> On 01/18/2016 09:54 AM, John Snow wrote:
>>
>>>> Please, let's decide finally about extra data, than I'll reroll it and,
>>>> I hope, it will be committed, to make it possible to continue work on
>>>> persistence series. About extra data, I'm ready to accept any variant,
>>>> strictly defining, what software should do with unknown extra data.
>>>>
>>>>
>>> I discussed this with Eric Blake on IRC briefly, and I mentioned I was
>>> concerned that we didn't specify a format at all for the extra data.
>>> Eric felt that it was not unusual to leave a space for future expansion
>>> and that as we haven't used it yet, we don't need to solidify it.
>>>
>>> He also felt it would be unusual to stipulate the format of data that we
>>> don't even intend to use yet.
>>>
>>> In short, I'm being too proactive.
>>>
>>> A commit message mention that, should anyone wish to expand the
>>> type-specific data in the future that adding a 2-byte version as the
>>> first field in extra data would probably be sufficient, and we can worry
>>> about the spec wording later. It is fine to assume for now that if
>>> extra_data_size is 0 that the version/format of the data is "v0" and
>>> that does not limit our future expansion.
>> Or put another way:
>>
>> I'm just fine if our initial implementation provides sufficient
>> information for us to completely parse the file even when the file is
>> generated by a newer qemu (we have a length, so we know how far to skip
>> to find the next entry), while at the same time throwing up our hands if
>> the length is non-zero (we won't read the bitmap at all, because we
>> don't know if the non-zero extra_data contains instructions that would
>> change how to interpret the data) or even prevent writes (if the bitmap
>> entry is marked automatic, we must refuse any write that would requiring
>> an update to the bitmap because we don't know how to write to a bitmap
>> while correctly preserving semantics of those extra_data bytes).
> Can we assume that the extra_data doesn't contain references to
> clusters? Otherwise we need to forbid 'qemu-img check -r leaks' when
> there is unknown extra_data.
>
> FWIW, this assumption is already made for snapshots, so it seems okay to
> make it here as well. But we could be explicit about it.

ok, will do.

>
> Kevin


-- 
Best regards,
Vladimir
* now, @virtuozzo.com instead of @parallels.com. Sorry for this inconvenience.