From patchwork Tue Mar 29 15:08:02 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kevin Wolf X-Patchwork-Id: 8688011 Return-Path: X-Original-To: patchwork-qemu-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id B3321C0553 for ; Tue, 29 Mar 2016 15:11:47 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 0FFC9201C0 for ; Tue, 29 Mar 2016 15:11:47 +0000 (UTC) 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.kernel.org (Postfix) with ESMTPS id 48D0A20165 for ; Tue, 29 Mar 2016 15:11:46 +0000 (UTC) Received: from localhost ([::1]:47692 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akvJ3-0006Ec-I5 for patchwork-qemu-devel@patchwork.kernel.org; Tue, 29 Mar 2016 11:11:45 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39584) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akvGj-0002Qa-56 for qemu-devel@nongnu.org; Tue, 29 Mar 2016 11:09:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akvGd-000615-Cw for qemu-devel@nongnu.org; Tue, 29 Mar 2016 11:09:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53184) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akvGW-0005yh-Dm; Tue, 29 Mar 2016 11:09:08 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 05E733407EC; Tue, 29 Mar 2016 15:09:08 +0000 (UTC) Received: from noname.redhat.com (ovpn-116-120.ams2.redhat.com [10.36.116.120]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2TF912d011786; Tue, 29 Mar 2016 11:09:06 -0400 From: Kevin Wolf To: qemu-block@nongnu.org Date: Tue, 29 Mar 2016 17:08:02 +0200 Message-Id: <1459264128-12761-3-git-send-email-kwolf@redhat.com> In-Reply-To: <1459264128-12761-1-git-send-email-kwolf@redhat.com> References: <1459264128-12761-1-git-send-email-kwolf@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 209.132.183.28 Cc: kwolf@redhat.com, qemu-devel@nongnu.org Subject: [Qemu-devel] [PULL 02/48] block: Remove copy-on-read from bdrv_move_feature_fields() X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Ever since we first introduced bdrv_append() in commit 8802d1fd ('qapi: Introduce blockdev-group-snapshot-sync command'), the copy-on-read flag was moved to the new top layer when taking a snapshot. The only problem is that it doesn't make a whole lot of sense. The use case for manually enabled CoR is to avoid reading data twice from a slow remote image, so we want to save it to a local overlay, say an ISO image accessed via HTTP to a local qcow2 overlay. When taking a snapshot, we end up with a backing chain like this: http <- local.qcow2 <- snap_overlay.qcow2 There is no point in doing CoR from local.qcow2 into snap_overlay.qcow2, we just want to keep copying data from the remote source into local.qcow2. The other use case of CoR is in the context of streaming, which isn't very interesting for bdrv_move_feature_fields() because op blockers prevent this combination. This patch makes the copy-on-read flag stay on the image for which it was originally set and prevents it from being propagated to the new overlay. It is no longer intended to move CoR to the BlockBackend level. In order for this to make sense, we also need to keep the respective image read-write. As a side effect of these changes, creating a live snapshot image (as opposed to using an existing externally created one) on top of a COR block device works now. It used to fail because it tried to open its backing file both read-only and with COR. Signed-off-by: Kevin Wolf Reviewed-by: Eric Blake --- block.c | 2 -- blockdev.c | 7 +++++-- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/block.c b/block.c index e0b280b..ee34c8c 100644 --- a/block.c +++ b/block.c @@ -2248,8 +2248,6 @@ static void bdrv_move_feature_fields(BlockDriverState *bs_dest, /* move some fields that need to stay attached to the device */ /* dev info */ - bs_dest->copy_on_read = bs_src->copy_on_read; - bs_dest->enable_write_cache = bs_src->enable_write_cache; /* dirty bitmap */ diff --git a/blockdev.c b/blockdev.c index 35f8515..914b526 100644 --- a/blockdev.c +++ b/blockdev.c @@ -1741,6 +1741,7 @@ static void external_snapshot_prepare(BlkActionState *common, } flags = state->old_bs->open_flags; + flags &= ~(BDRV_O_SNAPSHOT | BDRV_O_NO_BACKING | BDRV_O_COPY_ON_READ); /* create new image w/backing file */ mode = s->has_mode ? s->mode : NEW_IMAGE_MODE_ABSOLUTE_PATHS; @@ -1811,8 +1812,10 @@ static void external_snapshot_commit(BlkActionState *common) /* We don't need (or want) to use the transactional * bdrv_reopen_multiple() across all the entries at once, because we * don't want to abort all of them if one of them fails the reopen */ - bdrv_reopen(state->old_bs, state->old_bs->open_flags & ~BDRV_O_RDWR, - NULL); + if (!state->old_bs->copy_on_read) { + bdrv_reopen(state->old_bs, state->old_bs->open_flags & ~BDRV_O_RDWR, + NULL); + } } static void external_snapshot_abort(BlkActionState *common)