From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39286) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLa4M-0006sF-CX for qemu-devel@nongnu.org; Tue, 19 Jan 2016 12:27:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLa4I-0006ZS-I9 for qemu-devel@nongnu.org; Tue, 19 Jan 2016 12:27:50 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42216) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLa4I-0006ZM-BR for qemu-devel@nongnu.org; Tue, 19 Jan 2016 12:27:46 -0500 Date: Tue, 19 Jan 2016 18:27:43 +0100 From: Kevin Wolf Message-ID: <20160119172743.GF4579@noname.redhat.com> 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline In-Reply-To: <569D5648.6030605@redhat.com> 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: Eric Blake Cc: Vladimir Sementsov-Ogievskiy , famz@redhat.com, qemu-devel@nongnu.org, mreitz@redhat.com, stefanha@redhat.com, den@openvz.org, John Snow --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 18.01.2016 um 22:16 hat Eric Blake geschrieben: > On 01/18/2016 09:54 AM, John Snow wrote: >=20 > >> 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. > >> > >> > >=20 > > 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. > >=20 > > He also felt it would be unusual to stipulate the format of data that we > > don't even intend to use yet. > >=20 > > In short, I'm being too proactive. > >=20 > > 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. >=20 > Or put another way: >=20 > 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 --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJWnnIPAAoJEH8JsnLIjy/WbAoP/1tGvKtRmo5kkEW1rAa9qsmo fSHDkTxYgVI1bCHB6TTkbTYR6MygbrOG0ce+n8UPxwM+zqTnyp++klIRUBX3moC/ Wxt36icSjaKJa3x6XpRUbxIcDafZ5u4D61kiI8IBqWoFbcZTf7t71ariz1MWljxB ZQaJAA/Ji1BnAu2T7a7GcTwiu9kw2l1dqw2TwpEIZKeZs6vUAJ/+F8a9LpFts0B8 7D+Fj0xjf9s7xmudUEdK2kloOYokwntnGjq/4ORDdRQfA2cja3HiNfbYbFRMNglg Gwfr+tdP7bPLN9KEnKgINazt1XXVE7Pud1afAA7voKq9EylxYdE/rHCy5nExFZeq puk5uDLFTKxTvt+zaIssk1bsA6/wuQ2pq9xVoDnVIIWm66V2792CjBMKFkeYq5dB lC3ZRBnmhXdczy57lYl4LPpVOmBtNW9QCmB7Izt5u2C7q+9mbY1Cvzxr0xVYS1E0 1DlyTCV6LzWLD/1Ebp9+x4KPVW+18L6ycjCgq+pGSxIXamzq1PiUNrNc3Ev7jmTJ yhq5HsG/bbFgYdCIVVSyztMjhTR3uLpisTEAmK7UMmCzslXmJ8GBIY3eauJkxJPr wuf4ipF98T/zfSTW7PsptXWJgtXtcLW+SFLno0gkXILQQRmrS0gjLNR2ul6aT3bE nLk9rwSEV0b33bNr50OB =FprG -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu--