From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49524) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bIY1i-0006Oo-0n for qemu-devel@nongnu.org; Thu, 30 Jun 2016 05:12:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bIY1f-0003w9-UK for qemu-devel@nongnu.org; Thu, 30 Jun 2016 05:12:48 -0400 References: <1467272042-5195-1-git-send-email-vsementsov@virtuozzo.com> From: "Denis V. Lunev" Message-ID: <5774E27D.60003@openvz.org> Date: Thu, 30 Jun 2016 12:12:29 +0300 MIME-Version: 1.0 In-Reply-To: <1467272042-5195-1-git-send-email-vsementsov@virtuozzo.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] spec/qcow2: bitmaps: zero bitmap table offset List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladimir Sementsov-Ogievskiy , qemu-devel@nongnu.org Cc: qemu-block@nongnu.org, kwolf@redhat.com, eblake@redhat.com, jsnow@redhat.com, stefanha@redhat.com, famz@redhat.com, mreitz@redhat.com On 06/30/2016 10:34 AM, Vladimir Sementsov-Ogievskiy wrote: > After loading bitmap from image and setting IN_USE flag in it's header, > corresponding data (bitmap table and data clusters) becomes inconsistent > and is no longer needed. It is better to free bitmap table and > corresponding clusters from the image immediately after loading the > bitmap than free them when the bitmap is saved, or deleted or set > non-persistent. > > For now it is impossible to store only bitmap header without bitmap > table, as specification requires it. Storing zeroed bitmap table (one or > more clusters) is the only option to implement the behaviour similar to > specified above. > > The same problem is for just storing empty bitmaps. > > This patch allows storing only bitmap header for empty bitmaps. > > Signed-off-by: Vladimir Sementsov-Ogievskiy > --- > > Additional note. Should we also allow here bitmap_table_offset = 1, like > in bitmap table, for the bitmap with all bits set? I am not sure that it > is needed at all, but just to keep the company.. > > docs/specs/qcow2.txt | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/docs/specs/qcow2.txt b/docs/specs/qcow2.txt > index 80cdfd0..9826222 100644 > --- a/docs/specs/qcow2.txt > +++ b/docs/specs/qcow2.txt > @@ -435,9 +435,12 @@ Structure of a bitmap directory entry: > Offset into the image file at which the bitmap table > (described below) for the bitmap starts. Must be aligned to > a cluster boundary. > + Zero value means that bitmap table is not allocated and the > + bitmap should be considered as empty (all bits are zero). > > 8 - 11: bitmap_table_size > - Number of entries in the bitmap table of the bitmap. > + Number of entries in the bitmap table of the bitmap. It > + must be zero if bitmap_table_offset is zero. > > 12 - 15: flags > Bit NACK no guys, we can not make this change at the moment. We do have QEMU available in the field which is working with the currently specified format. Den