From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59821) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2zXG-0004dK-4B for qemu-devel@nongnu.org; Thu, 11 Jun 2015 06:16:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z2zXB-0008SA-4P for qemu-devel@nongnu.org; Thu, 11 Jun 2015 06:16:34 -0400 Received: from mx2.parallels.com ([199.115.105.18]:54594) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2zXA-0008Rt-Ud for qemu-devel@nongnu.org; Thu, 11 Jun 2015 06:16:29 -0400 Message-ID: <55795FEE.90300@virtuozzo.com> Date: Thu, 11 Jun 2015 13:16:14 +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> <557834D4.2070007@redhat.com> In-Reply-To: <557834D4.2070007@redhat.com> Content-Type: text/plain; charset="utf-8"; 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: Eric Blake , 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 On 10.06.2015 16:00, Eric Blake wrote: > 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 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? > "dirty bitmaps table" works for me, as a name for the one-level table. > for now, dirty bitmaps table is the table with bitmap descriptors, and each bitmap descriptor contains its own l1 table.. What about dirty bitmap directory for descriptors and dirty bitmap table for l1? like pde pte) -- Best regards, Vladimir * now, @virtuozzo.com instead of @parallels.com. Sorry for this inconvenience.