[Top][All Lists]

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

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

From: Vladimir Sementsov-Ogievskiy
Subject: Re: [Qemu-devel] [PATCH v7] spec: add qcow2 bitmaps extension specification
Date: Mon, 25 Jan 2016 13:22:37 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0

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.


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

reply via email to

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