On 2018-02-22 13:27, Kevin Wolf wrote:
> Am 05.02.2018 um 16:18 hat Max Reitz geschrieben:
>> When invoking drive-mirror in absolute-paths mode, the target's backing
>> BDS is assigned to it in mirror_exit(). The current logic only does so
>> if the target does not have that backing BDS already; but it actually
>> cannot have a backing BDS at all (the BDS is opened with O_NO_BACKING in
>> qmp_drive_mirror()), so just assert that and assign the new backing BDS
>> unconditionally.
>> Signed-off-by: Max Reitz <mre...@redhat.com>
>> Reviewed-by: Alberto Garcia <be...@igalia.com>
> Introducing new assumptions that the graph stays unmodified between the
> start of a block job and its completion feels a bit adventurous when all
> of the blockdev work is moving towards making things more flexible.

But as the commit message hints at, MIRROR_SOURCE_BACKING_CHAIN is used
only by drive-mirror.  How flexible do you intend that to be?

Yes, technically you can specify a node name for the newly created image
and then go wild while the block job is still running.  But then
something inside me feels like you should see your VM crashing for
that...  OTOH, a crash is always bad.

I can't make it crash in the current state because the mirror job
creates a BB and blockdev-snapshot thus refuses to attach a backing file
to the target.  But I guess I'll drop this patch anyway (unless I find
it was important for some other patch in this series, which I hope it

On a totally unrelated note, we need some protocol for hurting the user
if they do something that deserves a bit of pain.  Crashing is always
bad and our fault, so it needs to be something else.  Removing $HOME?
Marking all attached qcow2 images corrupt even though they aren't so you
have to run a qemu-img check?  I like that one.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to