From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58019) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2fcZ-0001g8-H7 for qemu-devel@nongnu.org; Wed, 10 Jun 2015 09:01:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z2fcA-0002kQ-66 for qemu-devel@nongnu.org; Wed, 10 Jun 2015 09:00:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56708) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2fc9-0002jz-Vy for qemu-devel@nongnu.org; Wed, 10 Jun 2015 09:00:18 -0400 Message-ID: <557834D4.2070007@redhat.com> Date: Wed, 10 Jun 2015 07:00:04 -0600 From: Eric Blake MIME-Version: 1.0 References: <1433776886-27239-1-git-send-email-vsementsov@virtuozzo.com> <1433776886-27239-2-git-send-email-vsementsov@virtuozzo.com> <20150609170325.GI3181@stefanha-thinkpad.redhat.com> <5577F312.9040502@virtuozzo.com> In-Reply-To: <5577F312.9040502@virtuozzo.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PPQJaMvpjJsWV7A9sIfkX5LvwALubam5K" Subject: Re: [Qemu-devel] [PATCH 1/8] spec: add qcow2-dirty-bitmaps specification List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladimir Sementsov-Ogievskiy , Stefan Hajnoczi Cc: kwolf@redhat.com, qemu-devel@nongnu.org, Vladimir Sementsov-Ogievskiy , stefanha@redhat.com, pbonzini@redhat.com, den@openvz.org, jsnow@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PPQJaMvpjJsWV7A9sIfkX5LvwALubam5K Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06/10/2015 02:19 AM, Vladimir Sementsov-Ogievskiy wrote: >>> +Dirty bitmaps is an optional header extension. It provides a >>> possibility of >>> +storing dirty bitmaps in qcow2 image. The fields are: >>> + >>> + 0 - 3: nb_dirty_bitmaps >>> + Number of dirty bitmaps contained in the image >> Is there a maximum? > hmm. any proposals for this? >> >>> + >>> + 4 - 11: dirty_bitmaps_offset I'm not sure if there is a reasonable cap on the number of dirty bitmaps; I doubt that anyone will actually supply all 4G possible images allowed by the four-byte field, but don't have a suggestion on a smaller limit that doesn't feel arbitrary. [meta-comment] It's very hard to pick out the new content in your reply if you do not separate your new text with a newline both before and after (as I'm doing here). >>> +Dirty bitmaps are stored using a ONE-level structure for the mapping= of >>> +bitmaps to host clusters. There is only an L1 table. >>> + >>> +The L1 table has a variable size (stored in the Bitmap table entry) >>> and may >>> +use multiple clusters, however it must be contiguous in the image fi= le. >> The use of "L1 table" could be confusing. The refcount metadata uses >> "refcount table" and "refcount block" to describe a one-level table. > I agree. Hmm.. dirty bitmaps table? ok? "dirty bitmaps table" works for me, as a name for the one-level table. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --PPQJaMvpjJsWV7A9sIfkX5LvwALubam5K 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/ iQEcBAEBCAAGBQJVeDTUAAoJEKeha0olJ0NqrIsIAKaulq23qPCa44PP+LT0CIBv ZBjUfF0q7NuyXWFUThf5z0B0Q96TbEOEIHo22UvCmaOL95hBnqweJFpfPT1p1acC QkpiVoo8rAwl6dpJ516DKuQ/opAClE210OUUFIlJZeGUm/R//ul9tLKkjcfLjqaX 8JN2jTsWspKeH5BCS4zvefxU0BRnez+4Gc9GsDwgUiyQX5hPIZcw8jzw8aTulMbC 7zSmWoDNHrPjcL1Q3CUwdqow2n3CMCUKASJQxfDVUwqn3nk7mIqT+OaTg9CuTU60 d/BlbseC2QY3fGRTn+6hm6VJY2WCQ9MOGqrxSRaqi/sBbDdZGIc8UBlO91J98pQ= =hfSp -----END PGP SIGNATURE----- --PPQJaMvpjJsWV7A9sIfkX5LvwALubam5K--