qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Max Reitz <mreitz@redhat.com>
Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org,
	Fam Zheng <famz@redhat.com>,
	nsoffer@redhat.com, eblake@redhat.com, pbonzini@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2 2/3] block/mirror: Fix target backing BDS
Date: Wed, 8 Jun 2016 11:32:29 +0200	[thread overview]
Message-ID: <20160608093229.GC5324@noname.str.redhat.com> (raw)
In-Reply-To: <20160606144212.24074-3-mreitz@redhat.com>

Am 06.06.2016 um 16:42 hat Max Reitz geschrieben:
> Currently, we are trying to move the backing BDS from the source to the
> target in bdrv_replace_in_backing_chain() which is called from
> mirror_exit(). However, mirror_complete() already tries to open the
> target's backing chain with a call to bdrv_open_backing_file().
> 
> First, we should only set the target's backing BDS once. Second, the
> mirroring block job has a better idea of what to set it to than the
> generic code in bdrv_replace_in_backing_chain() (in fact, the latter's
> conditions on when to move the backing BDS from source to target are not
> really correct).
> 
> Therefore, remove that code from bdrv_replace_in_backing_chain() and
> leave it to mirror_complete().
> 
> However, mirror_complete() in turn pursues a questionable strategy by
> employing bdrv_open_backing_file(): On the one hand, because this may
> open the wrong backing file with drive-mirror in "existing" mode, or
> because it will not override a possibly wrong backing file in the
> blockdev-mirror case.
> 
> On the other hand, we want to reuse the existing backing chain of the
> source instead of opening everything anew, because the latter results in
> having multiple BDSs for a single physical file and thus potentially
> concurrent access which we should try to avoid.

Careful, this "wrong" backing file might actually be intended!

Consider a case where you want to move an image with its whole backing
chain to different storage. In that case, you would copy all of the
backing files (cp is good enough, they are read-only), create the
destination image which already points at the copied backing chain, and
then mirror in "existing" mode.

The intention is obviously that after the job completion the new backing
chain is used and not the old one.

I know that such cases were discussed when mirroring was introduced, I'm
not sure whether it's actually used. We need some input there:

Eric, can you tell us whether libvirt makes use of such a setup?

Nir, I'm not sure who is the right person in oVirt these days, but do
you either know yourself whether oVirt requires this to work, or do you
know who else would know?

> Thus, instead of invoking bdrv_open_backing_file(), just set the correct
> backing BDS directly via bdrv_set_backing_hd(). Also, do so only when
> mirror_complete() is certain to succeed.
> 
> In contrast to what bdrv_replace_in_backing_chain() did so far, we do
> not need to drop the source's backing file.
> 
> Signed-off-by: Max Reitz <mreitz@redhat.com>

Leaving the actual code review for later when we have decided what
semantics we even want.

Kevin

  reply	other threads:[~2016-06-08  9:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-06 14:42 [Qemu-devel] [PATCH v2 0/3] block/mirror: Fix target backing BDS Max Reitz
2016-06-06 14:42 ` [Qemu-devel] [PATCH v2 1/3] block: Allow replacement of a BDS by its overlay Max Reitz
2016-06-08  8:58   ` Kevin Wolf
2016-06-08 14:21     ` Max Reitz
2016-06-06 14:42 ` [Qemu-devel] [PATCH v2 2/3] block/mirror: Fix target backing BDS Max Reitz
2016-06-08  9:32   ` Kevin Wolf [this message]
2016-06-08 11:28     ` Paolo Bonzini
2016-06-08 11:47       ` Kevin Wolf
2016-06-08 14:40       ` Max Reitz
2016-06-08 14:42         ` Max Reitz
2016-06-08 14:38     ` Max Reitz
2016-06-08 16:54       ` Max Reitz
2016-06-08 15:39     ` Nir Soffer
2016-06-09  8:58       ` Kevin Wolf
2016-06-09 11:16         ` Nir Soffer
2016-06-06 14:42 ` [Qemu-devel] [PATCH v2 3/3] iotests: Add test for post-mirror backing chains Max Reitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160608093229.GC5324@noname.str.redhat.com \
    --to=kwolf@redhat.com \
    --cc=eblake@redhat.com \
    --cc=famz@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=nsoffer@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).