From patchwork Thu Jun 30 07:34:02 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Sementsov-Ogievskiy X-Patchwork-Id: 9206835 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 5748660752 for ; Thu, 30 Jun 2016 07:47:28 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4AD9B284F5 for ; Thu, 30 Jun 2016 07:47:28 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 3F7D4285BA; Thu, 30 Jun 2016 07:47:28 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id B7C98284F5 for ; Thu, 30 Jun 2016 07:47:27 +0000 (UTC) Received: from localhost ([::1]:47530 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bIWh4-0002CK-Ph for patchwork-qemu-devel@patchwork.kernel.org; Thu, 30 Jun 2016 03:47:26 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58260) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bIWUn-0003jD-6e for qemu-devel@nongnu.org; Thu, 30 Jun 2016 03:34:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bIWUl-0007aL-BP for qemu-devel@nongnu.org; Thu, 30 Jun 2016 03:34:44 -0400 Received: from mailhub.sw.ru ([195.214.232.25]:41259 helo=relay.sw.ru) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bIWUk-0007aA-VG for qemu-devel@nongnu.org; Thu, 30 Jun 2016 03:34:43 -0400 Received: from kvm.sw.ru. ([10.28.8.145]) by relay.sw.ru (8.13.4/8.13.4) with ESMTP id u5U7YGZZ020859; Thu, 30 Jun 2016 10:34:18 +0300 (MSK) From: Vladimir Sementsov-Ogievskiy To: qemu-devel@nongnu.org Date: Thu, 30 Jun 2016 10:34:02 +0300 Message-Id: <1467272042-5195-1-git-send-email-vsementsov@virtuozzo.com> X-Mailer: git-send-email 1.8.3.1 X-detected-operating-system: by eggs.gnu.org: OpenBSD 3.x X-Received-From: 195.214.232.25 Subject: [Qemu-devel] [PATCH v2] spec/qcow2: bitmaps: zero bitmap table offset X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kwolf@redhat.com, vsementsov@virtuozzo.com, famz@redhat.com, qemu-block@nongnu.org, mreitz@redhat.com, stefanha@redhat.com, den@openvz.org, jsnow@redhat.com Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP 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