From patchwork Tue Mar 5 23:43:32 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Snow X-Patchwork-Id: 10840213 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 3C1691669 for ; Tue, 5 Mar 2019 23:45:16 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2534B2C4C2 for ; Tue, 5 Mar 2019 23:45:16 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 13B3D2CEC9; Tue, 5 Mar 2019 23:45:16 +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=-2.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 968212C4C2 for ; Tue, 5 Mar 2019 23:45:15 +0000 (UTC) Received: from localhost ([127.0.0.1]:51063 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h1JkI-0008NR-3C for patchwork-qemu-devel@patchwork.kernel.org; Tue, 05 Mar 2019 18:45:14 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40329) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h1Jiv-0007GF-0N for qemu-devel@nongnu.org; Tue, 05 Mar 2019 18:43:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h1Jiq-0005jS-NK for qemu-devel@nongnu.org; Tue, 05 Mar 2019 18:43:47 -0500 Received: from mx1.redhat.com ([209.132.183.28]:60072) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h1Jio-0005dq-I4; Tue, 05 Mar 2019 18:43:42 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9E355308213A; Tue, 5 Mar 2019 23:43:40 +0000 (UTC) Received: from probe.bos.redhat.com (dhcp-17-232.bos.redhat.com [10.18.17.232]) by smtp.corp.redhat.com (Postfix) with ESMTP id C60266109B; Tue, 5 Mar 2019 23:43:37 +0000 (UTC) From: John Snow To: qemu-devel@nongnu.org Date: Tue, 5 Mar 2019 18:43:32 -0500 Message-Id: <20190305234337.18353-1-jsnow@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.42]); Tue, 05 Mar 2019 23:43:40 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH 0/5] block/qcow2-bitmap: Enable resize with persistent bitmaps 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: Kevin Wolf , vsementsov@virtuozzo.com, qemu-block@nongnu.org, Max Reitz , John Snow Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP This series aims to enable block resizes when persistent bitmaps are in use. The basic approach here is to recognize that we now load all persistent bitmaps in memory, and so we can rely on in-memory resizes and then flush the changed metadata back to disk. One part that is potentially now quite strange is that bitmap resizes may happen twice: once during the qcow2 resize event only if persistent bitmaps are found, and then again as part of the generic resize callback event whether or not we have any persistent bitmaps. The second round is required if we are not using qcow2 or we have only transient bitmaps. The first round is required as we wish to flush the bitmaps back to disk atomically with the qcow2 resize to avoid violating our invariants for the bitmap metadata which is checked in many places. This is harmless; hbitmap_truncate will recognize the second round as a no-op. John Snow (5): block/qcow2-bitmap: Skip length check in some cases block/qcow2-bitmap: Allow bitmap flushing block/qcow2-bitmap: don't remove bitmaps on reopen block/qcow2-bitmap: Allow resizes with persistent bitmaps tests/qemu-iotests: add bitmap resize test 246 block/qcow2.h | 2 + block/qcow2-bitmap.c | 123 +++++++++++---- block/qcow2.c | 27 +++- tests/qemu-iotests/246 | 114 ++++++++++++++ tests/qemu-iotests/246.out | 296 +++++++++++++++++++++++++++++++++++++ tests/qemu-iotests/group | 1 + 6 files changed, 528 insertions(+), 35 deletions(-) create mode 100755 tests/qemu-iotests/246 create mode 100644 tests/qemu-iotests/246.out