From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48434) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRCqK-0007du-QK for qemu-devel@nongnu.org; Thu, 04 Feb 2016 00:52:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aRCqF-0003Ud-Pt for qemu-devel@nongnu.org; Thu, 04 Feb 2016 00:52:36 -0500 Received: from mx2.parallels.com ([199.115.105.18]:56052) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRCqF-0003UX-JV for qemu-devel@nongnu.org; Thu, 04 Feb 2016 00:52:31 -0500 Message-ID: <56B2E70F.8030404@virtuozzo.com> Date: Thu, 4 Feb 2016 08:52:15 +0300 From: Vladimir Sementsov-Ogievskiy MIME-Version: 1.0 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> <20160204022520.GC5187@ad.usersys.redhat.com> In-Reply-To: <20160204022520.GC5187@ad.usersys.redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit 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: Fam Zheng Cc: kwolf@redhat.com, den@openvz.org, jsnow@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com On 04.02.2016 05:25, Fam Zheng wrote: > 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 And what the meaning of bits[9..55] in case of bit[0] = 1? "Reserved" is better here, I think, than "ignored". In other places of this doc we switched from "ignored" to "reserved" during this discussion. For example in case of snapshot-switch we will (may be) set all bits in the bitmap. Frequency of sync doesn't matter, the bitmaps becomes more and more dirty and it will be cleared only after next incremental backup. "this bit is hard to use" - even if it is hard, you are not forced to use it: you can allocate cluster and set all bits in it (or unset them) and leave bit[0] = zero. It is an additional feature, which will save disk space and io in some cases. > > Fam -- Best regards, Vladimir