From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52032) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBt2d-0007bj-3b for qemu-devel@nongnu.org; Wed, 23 Dec 2015 18:42:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aBt2Z-0003qK-RT for qemu-devel@nongnu.org; Wed, 23 Dec 2015 18:41:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50874) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aBt2Z-0003q3-J3 for qemu-devel@nongnu.org; Wed, 23 Dec 2015 18:41:55 -0500 References: <1450892961-6495-1-git-send-email-vsementsov@virtuozzo.com> From: Eric Blake Message-ID: <567B313D.4020607@redhat.com> Date: Wed, 23 Dec 2015 16:41:49 -0700 MIME-Version: 1.0 In-Reply-To: <1450892961-6495-1-git-send-email-vsementsov@virtuozzo.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="R5Qa2CqV34pnoDcTn6ULjvIMNEIVaDfrP" Subject: Re: [Qemu-devel] [PATCH v6] spec: add qcow2 bitmaps extension specification List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladimir Sementsov-Ogievskiy , qemu-devel@nongnu.org Cc: kwolf@redhat.com, famz@redhat.com, mreitz@redhat.com, stefanha@redhat.com, den@openvz.org, jsnow@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --R5Qa2CqV34pnoDcTn6ULjvIMNEIVaDfrP Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/23/2015 10:49 AM, Vladimir Sementsov-Ogievskiy wrote: > The new feature for qcow2: storing bitmaps. >=20 > This patch adds new header extension to qcow2 - Bitmaps Extension. It > provides an ability to store virtual disk related bitmaps in a qcow2 > image. For now there is only one type of such bitmaps: Dirty Tracking > Bitmap, which just tracks virtual disk changes from some moment. >=20 > Note: Only bitmaps, relative to the virtual disk, stored in qcow2 file,= > should be stored in this qcow2 file. The size of each bitmap > (considering its granularity) is equal to virtual disk size. >=20 > Signed-off-by: Vladimir Sementsov-Ogievskiy > --- >=20 > @@ -166,6 +179,34 @@ the header extension data. Each entry look like th= is: > terminated if it has full length) > =20 > =20 > +=3D=3D Bitmaps extension =3D=3D > + > +Bitmaps extension is an optional header extension. It provides an abil= ity to > +store virtual disk related bitmaps in a qcow2 image. For now there is = only one > +type of such bitmaps: Dirty Tracking Bitmap, which just tracks virtual= disk > +changes from some moment. This is already the qcow2 spec, so 'in a qcow2 image' may be redundant. Possible idea for nicer grammar: It provides the ability to store bitmaps related to a virtual disk. For now, there is only one bitmap type: Dirty Tracking Bitmap, which tracks virtual disk changes from some moment. > + 17: granularity_bits > + Granularity bits. Valid values are: 0 - 63. Elsewhere, the file has 'valid values: 0-63'; dropping 'are' would make this more consistent. > + > + Note: Qemu currently doesn't support granularity_b= its > + greater than 31. > + > + Granularity is calculated as > + granularity =3D 1 << granularity_bits > + > + Granularity of the bitmap is how many bytes of the= image > + accounts for one bit of the bitmap. > + > + 18 - 19: name_size > + Size of the bitmap name. Valid values: 1 - 1023. Should this be more like: Must be non-zero. Note: Qemu currently doesn't support values greater than 1023. > +=3D=3D=3D Bitmap Data =3D=3D=3D > + > +As noted above, bitmap data is stored in several (or may be one, exact= ly > +bitmap_table_size) separate clusters, described by Bitmap Table. bitmap_table_size was documented as "Number of entries in the Bitmap Table of the bitmap", where each entry is 8 bytes. But this sounds like bitmap_table_size =3D=3D 1 implies that the table is exactly 1 cluster (a= t least 512 bytes). I think you are trying to imply that the bitmap data occupies ceil(cluster size / 8 / bitmap_tablesize) clusters. I also wonder if you need more text to cover what happens when the number of entries does not end on a cluster boundary. Must the remaining bits of the cluster containing the tail of the Bitmap be set to all 0, or is it garbage that must be ignored regardless of content? --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --R5Qa2CqV34pnoDcTn6ULjvIMNEIVaDfrP 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/ iQEcBAEBCAAGBQJWezE9AAoJEKeha0olJ0NqDBoH+gJ2LttBN9xT8mEpeX8E3a8O hwuV7t6Kf9sGJ2NMZKGVlHewlNNtWo6zf13TVfRhwxUb+LFB/d7ebU69bhNfBYGT jexrVQJFL1PczU5THQ0pA0Cec503/pMCl/yDuwoRweVmOqvqPrqZYXoMZC//0ka/ RKTe5b53KhYxEatqs+Ec5TF0zANJ1aAWz8QBBZxGeAeKFFzlqX9nQCdD6yejfD// 4Fl4sBteq5Cn8zv7uxiDZh5VYq6K85f4UnKAvAac3Zgd3KMX6tHcvFgDOHx+Q4iZ 9pQWRlsYmU7Psp4m9lVKHhTFInTW80jlTr8rc9BnJ1uBcDBxjwWISn6GO+RoFYI= =qQGq -----END PGP SIGNATURE----- --R5Qa2CqV34pnoDcTn6ULjvIMNEIVaDfrP--