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

[Kevin Wolf]

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.

Kevin

pgpHBpjLtNLUk.pgp
Description: PGP signature