From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58225) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aR9bs-0003fn-My for qemu-devel@nongnu.org; Wed, 03 Feb 2016 21:25:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aR9bp-0007Qt-G8 for qemu-devel@nongnu.org; Wed, 03 Feb 2016 21:25:28 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55196) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aR9bp-0007Ql-AY for qemu-devel@nongnu.org; Wed, 03 Feb 2016 21:25:25 -0500 Date: Thu, 4 Feb 2016 10:25:20 +0800 From: Fam Zheng Message-ID: <20160204022520.GC5187@ad.usersys.redhat.com> References: <1454394900-3586-1-git-send-email-vsementsov@virtuozzo.com> <20160203080401.GB25746@ad.usersys.redhat.com> <56B20471.6090804@virtuozzo.com> <20160203144114.GA1956@ad.usersys.redhat.com> <56B235EF.6000401@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56B235EF.6000401@virtuozzo.com> Subject: Re: [Qemu-devel] [PATCH v9] spec: add qcow2 bitmaps extension specification List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladimir Sementsov-Ogievskiy Cc: kwolf@redhat.com, den@openvz.org, jsnow@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com On Wed, 02/03 20:16, Vladimir Sementsov-Ogievskiy wrote: > On 03.02.2016 17:41, Fam Zheng wrote: > >On Wed, 02/03 16:45, Vladimir Sementsov-Ogievskiy wrote: > >>Also current scheme is made like one for snapshots. > >Okay, then I'll be fine with being consistent. > > > > > >>>>+ > >>>>+ > >>>>+=== Bitmap table === > >>>>+ > >>>>+Bitmaps are stored using a one-level structure (as opposed to two-level > >>>>+structure like for refcounts and guest clusters mapping) for the mapping of > >>>s/structure/structures/ > >>> > >>>>+bitmap data to host clusters. This structure is called the bitmap table. > >>>>+ > >>>>+Each bitmap table has a variable size (stored in the bitmap directory entry) > >>>>+and may use multiple clusters, however, it must be contiguous in the image > >>>>+file. > >>>>+ > >>>>+Structure of a bitmap table entry: > >>>>+ > >>>>+ Bit 0: Reserved and must be zero if bits 9 - 55 are non-zero. > >>>>+ If bits 9 - 55 are zero: > >>>>+ 0: Cluster should be read as all zeros. > >>>>+ 1: Cluster should be read as all ones. > >>>Once bits 9 - 55 are non-zero, this bit goes useless? That doesn't make much > >>>sense to me. In which case bit 0 is set but 9-55 are zero? > >>In case "1: Cluster should be read as all ones.". > >I cannot think of a use case leading to this. > > Why not? It is the dirty bitmap. It may be very dirty, it even may > be all-ones. I see what this is about. This assumes the bitmap is only saved when the image is closed, so that if by that time the whole chunk is all-one, this bit is set without allocating the cluster. But again, I don't think that is the only way to save bitmap: an implementation can save dirty bit much more frequently (to free memory), or even do it synchronously (to be power failure proof). In these cases, this bit is hard to use, because it's very unlikely all bits are dirtied between two adjacent saving points. Sorry for asking for this so late, what about making bit 0 and the offset orthogonal? Bits[9..55] = 0 | Bits[9..55] != 0 Bit[0] = 0 zero | read Bit[0] = 1 one | one Fam