From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33028) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjYvQ-00041b-Od for qemu-devel@nongnu.org; Tue, 06 Oct 2015 16:33:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZjYvN-0008A3-Vu for qemu-devel@nongnu.org; Tue, 06 Oct 2015 16:33:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42551) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjYvN-00089l-Ng for qemu-devel@nongnu.org; Tue, 06 Oct 2015 16:33:25 -0400 References: <1441471439-6157-1-git-send-email-vsementsov@virtuozzo.com> <1441471439-6157-4-git-send-email-vsementsov@virtuozzo.com> <55EB277D.9030700@virtuozzo.com> <56142D6A.1040501@redhat.com> From: Eric Blake Message-ID: <56143009.9090104@redhat.com> Date: Tue, 6 Oct 2015 14:33:13 -0600 MIME-Version: 1.0 In-Reply-To: <56142D6A.1040501@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="86BiIlN8WsuBCCg7314u3BJN287emBsle" Subject: Re: [Qemu-devel] [PATCH 03/17] spec: add qcow2-dirty-bitmaps specification List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow , Vladimir Sementsov-Ogievskiy , qemu-devel@nongnu.org Cc: kwolf@redhat.com, pbonzini@redhat.com, stefanha@redhat.com, den@openvz.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --86BiIlN8WsuBCCg7314u3BJN287emBsle Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/06/2015 02:22 PM, John Snow wrote: >>> +Dirty Bitmap Directory Entry: >>> + >>> + >>> + 24 - 27: flags >>> + Bit >>> + 0: in_use >>> + The bitmap is in use and may be inconsisten= t. >>> + >>> + 1: self >>> + The bitmap is a dirty bitmap for the >>> containing image. >>> + >>> + 2: auto >>> + The bitmap should be autoloaded as block >>> dirty bitmap. >>> + Only available if bit 1 (self) is set. >>> + >>> + 3: read_only >>> + The bitmap should not be rewritten. >>> + >>> + Bits 4 - 31 are reserved. >> >> Is this appropriate as field, reserved for future extensiion? Or we ne= ed >> an additional one? Do we need scheme like with snapshots? (somthing li= ke >> field 'additional_area_size', and additional offset of this size after= >> the name) >> >=20 > I think it would remain appropriate as long as we have a version header= > for the bitmap extension as a whole. Simply requiring that the bits must be 0 is good enough for now. >=20 > e.g. "Bits 4 - 31 are reserved in qcow2.bitmap.v1 ..." >=20 > If a program that only knows about v1 opens a v2 file and find it > conforms to spec (does not use the new reserved bits), then it can > continue along happily. I don't know that you even have to mention versions of the header, so much as the blanket statement that any set bit not described by this version of the spec is either a data corruption or evidence of a newer version of the spec having edited the file in the meantime. It works as long as you require conforming clients to set reserved bits to 0. >=20 > If a reserved bit is set, it's an error and the v1 program must not > alter the image in case it ruins the consistency of the file. >=20 > The usual suspects (Kevin, Markus, Stefan and Eric) may have better > suggestions for how to handle future compatibility by drawing upon thei= r > experience with qcow2. No, I think we're just fine. If any future spec version requires additional space, then it can use one of the bits 4-31 as a flag to call out that space, and older clients will handily refuse to operate on the file without having to know that the bit meant that the header occupied more space in the newer version of the spec. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --86BiIlN8WsuBCCg7314u3BJN287emBsle Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWFDAJAAoJEKeha0olJ0NqV5UH/0z0ETT1pe/+qWK0ThX/O4F/ VVxzgUnFpfBTid5vLzsgSzxLNl4M6SfDOk7Xz8XuN/t2c7546c6Q63mmnd+BHkKg ZZUc8QRnnuCOzDYsg6ESf+if63YGXBz24g1VD1XRFY1rS5Xq4mtW+oo5rQHuWM90 c5hZobrM07THe2x16dsg17Cl4tx3gWj4uFwHQtynK6dA78XqwHxGQcPIMluUPOcJ L7OE6AgB8Z4BvJjdKhZBpp9wPPzlw5WIzjpAyK8xNNF0l8Aj/eSZCIaRdEfXreEL Z/35NKtcc51wLsIcVhqnEzHpam2wPgIMEjwVz++MX6BUOz01LojRKcKcJRynRHE= =VmbE -----END PGP SIGNATURE----- --86BiIlN8WsuBCCg7314u3BJN287emBsle--