block: Remove copy-on-read from bdrv_move_feature_fields()
authorKevin Wolf <kwolf@redhat.com>
Mon, 29 Feb 2016 12:12:26 +0000 (13:12 +0100)
committerKevin Wolf <kwolf@redhat.com>
Wed, 30 Mar 2016 09:59:32 +0000 (11:59 +0200)
commit4c8449832c0add27b898e657a9e7e8603f44157c
tree27f18f918452d06a8b196f216a5609ee5b4b95f8
parent63eaaae08cb7738311f73d1a7e6e6a68ddf60688
block: Remove copy-on-read from bdrv_move_feature_fields()

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 <kwolf@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
block.c
blockdev.c