From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33466) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNeIW-000663-Id for qemu-devel@nongnu.org; Mon, 25 Jan 2016 05:23:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aNeIR-000128-IG for qemu-devel@nongnu.org; Mon, 25 Jan 2016 05:23:00 -0500 Received: from mx2.parallels.com ([199.115.105.18]:39868) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aNeIR-00011y-CB for qemu-devel@nongnu.org; Mon, 25 Jan 2016 05:22:55 -0500 Message-ID: <56A5F76D.4090706@virtuozzo.com> Date: Mon, 25 Jan 2016 13:22:37 +0300 From: Vladimir Sementsov-Ogievskiy MIME-Version: 1.0 References: <1452517517-3953-1-git-send-email-vsementsov@virtuozzo.com> <56981C60.9020005@redhat.com> <56982EA9.6030602@redhat.com> <569A4E71.5010004@virtuozzo.com> <569D18CE.5070104@redhat.com> <569D5648.6030605@redhat.com> <20160119172743.GF4579@noname.redhat.com> In-Reply-To: <20160119172743.GF4579@noname.redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v7] spec: add qcow2 bitmaps extension specification List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf , Eric Blake Cc: famz@redhat.com, qemu-devel@nongnu.org, mreitz@redhat.com, stefanha@redhat.com, den@openvz.org, John Snow 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.