From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60909) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2zaD-00065J-Fe for qemu-devel@nongnu.org; Thu, 11 Jun 2015 06:19:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z2za9-0000cQ-EJ for qemu-devel@nongnu.org; Thu, 11 Jun 2015 06:19:37 -0400 Received: from mx2.parallels.com ([199.115.105.18]:57313) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2za9-0000cM-9T for qemu-devel@nongnu.org; Thu, 11 Jun 2015 06:19:33 -0400 Message-ID: <557960AC.4080607@virtuozzo.com> Date: Thu, 11 Jun 2015 13:19:24 +0300 From: Vladimir Sementsov-Ogievskiy 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> <20150610132420.GD2430@stefanha-thinkpad.home> In-Reply-To: <20150610132420.GD2430@stefanha-thinkpad.home> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit 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: Stefan Hajnoczi Cc: kwolf@redhat.com, Stefan Hajnoczi , qemu-devel@nongnu.org, Vladimir Sementsov-Ogievskiy , pbonzini@redhat.com, den@openvz.org, jsnow@redhat.com On 10.06.2015 16:24, Stefan Hajnoczi wrote: > On Wed, Jun 10, 2015 at 11:19:30AM +0300, Vladimir Sementsov-Ogievskiy wrote: >> On 09.06.2015 20:03, Stefan Hajnoczi wrote: >>> On Mon, Jun 08, 2015 at 06:21:19PM +0300, Vladimir Sementsov-Ogievskiy wrote: >>>> @@ -166,6 +167,19 @@ the header extension data. Each entry look like this: >>>> terminated if it has full length) >>>> +== Dirty bitmaps == >>>> + >>>> +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? > 65535 seems practical. So, you suggest to reduce this field width to 2b? And additional 2 bytes reserved field, to achieve 8b-alignment? > >>>> +=== Cluster mapping === >>>> + >>>> +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 file. >>> 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? > Yes, that is good. > >>>> + >>>> +Given an offset into the bitmap, the offset into the image file can be >>>> +obtained as follows: >>>> + >>>> + offset = l1_table[offset / cluster_size] + (offset % cluster_size) >>> It might help to add granularity to this formula. >>> >>> Instead of "offset", "bit_number" or "bitnr" might be clearer since >>> "offset" means something different in other parts of the document. >> Hmm. In my opinion, the bitmap here is stored as raw data. And granularity >> is an additional parameter (for deserializing this data). So, it is an >> offset in bytes for this data. The format is not for accessing bitmap bits, >> it's only for loading the whole bitmap one time. > You are right, it wasn't clear when I read this the first time. My > problem was the "offset into the bitmap" doesn't have any units. So > let's make this more explicit. Can you document how to go from a bit > number down to the offset? -- Best regards, Vladimir * now, @virtuozzo.com instead of @parallels.com. Sorry for this inconvenience.