From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60244) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aC2u9-0006Ji-11 for qemu-devel@nongnu.org; Thu, 24 Dec 2015 05:13:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aC2u4-0006zY-1H for qemu-devel@nongnu.org; Thu, 24 Dec 2015 05:13:52 -0500 Received: from mx2.parallels.com ([199.115.105.18]:44940) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aC2u3-0006zF-RI for qemu-devel@nongnu.org; Thu, 24 Dec 2015 05:13:47 -0500 Message-ID: <567BC253.6090600@virtuozzo.com> Date: Thu, 24 Dec 2015 13:00:51 +0300 From: Vladimir Sementsov-Ogievskiy MIME-Version: 1.0 References: <1450892961-6495-1-git-send-email-vsementsov@virtuozzo.com> <567B313D.4020607@redhat.com> In-Reply-To: <567B313D.4020607@redhat.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit 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: Eric Blake , qemu-devel@nongnu.org Cc: kwolf@redhat.com, famz@redhat.com, mreitz@redhat.com, stefanha@redhat.com, den@openvz.org, jsnow@redhat.com On 24.12.2015 02:41, Eric Blake wrote: > On 12/23/2015 10:49 AM, Vladimir Sementsov-Ogievskiy wrote: >> The new feature for qcow2: storing bitmaps. >> >> 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. >> >> 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. >> >> Signed-off-by: Vladimir Sementsov-Ogievskiy >> --- >> >> @@ -166,6 +179,34 @@ the header extension data. Each entry look like this: >> terminated if it has full length) >> >> >> +== Bitmaps extension == >> + >> +Bitmaps extension is an optional header 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. > 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_bits >> + greater than 31. >> + >> + Granularity is calculated as >> + granularity = 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. > > >> +=== Bitmap Data === >> + >> +As noted above, bitmap data is stored in several (or may be one, exactly >> +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 == 1 implies that the table is exactly 1 cluster (at > least 512 bytes). I think you are trying to imply that the bitmap data > occupies ceil(cluster size / 8 / bitmap_tablesize) clusters. I don't understand.. No. Bitmap data occupies bitmap_table_size clusters. The last one may have some meaningless remaining bits. If bitmap_table_size = 1, than bitmap data is stored in "exactly 1" cluster. Bitmap table is like page table. > > 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? > -- Best regards, Vladimir * now, @virtuozzo.com instead of @parallels.com. Sorry for this inconvenience.