From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57269) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bAeek-0002nx-Ce for qemu-devel@nongnu.org; Wed, 08 Jun 2016 10:40:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bAeeg-0007HT-W9 for qemu-devel@nongnu.org; Wed, 08 Jun 2016 10:40:30 -0400 References: <20160606144212.24074-1-mreitz@redhat.com> <20160606144212.24074-3-mreitz@redhat.com> <20160608093229.GC5324@noname.str.redhat.com> <666270289.20792192.1465385289909.JavaMail.zimbra@redhat.com> From: Max Reitz Message-ID: Date: Wed, 8 Jun 2016 16:40:14 +0200 MIME-Version: 1.0 In-Reply-To: <666270289.20792192.1465385289909.JavaMail.zimbra@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jHjO4lK6hBtNs4Ror50jOPK2UbEFWoruF" Subject: Re: [Qemu-devel] [PATCH v2 2/3] block/mirror: Fix target backing BDS List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , Kevin Wolf Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org, Fam Zheng , nsoffer@redhat.com, eblake@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jHjO4lK6hBtNs4Ror50jOPK2UbEFWoruF From: Max Reitz To: Paolo Bonzini , Kevin Wolf Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org, Fam Zheng , nsoffer@redhat.com, eblake@redhat.com Message-ID: Subject: Re: [PATCH v2 2/3] block/mirror: Fix target backing BDS References: <20160606144212.24074-1-mreitz@redhat.com> <20160606144212.24074-3-mreitz@redhat.com> <20160608093229.GC5324@noname.str.redhat.com> <666270289.20792192.1465385289909.JavaMail.zimbra@redhat.com> In-Reply-To: <666270289.20792192.1465385289909.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 08.06.2016 13:28, Paolo Bonzini wrote: >=20 >=20 > ----- Original Message ----- >> From: "Kevin Wolf" >> To: "Max Reitz" >> Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org, "Fam Zheng" , nsoffer@redhat.com, >> eblake@redhat.com, pbonzini@redhat.com >> Sent: Wednesday, June 8, 2016 11:32:29 AM >> Subject: Re: [PATCH v2 2/3] block/mirror: Fix target backing BDS >> >> Am 06.06.2016 um 16:42 hat Max Reitz geschrieben: >>> Currently, we are trying to move the backing BDS from the source to t= he >>> 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. >> >> 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, an= d >> then mirror in "existing" mode. >> >> The intention is obviously that after the job completion the new backi= ng >> chain is used and not the old one. >=20 > Yes, this is the intention and it should not be changed. In addition > to what Kevin said, you can use drive-mirror to collapse the image to a= > single file; in this case, QEMU should not be using the backing files o= f > the source. That is an issue that we have right now. If you do drive-mirror in absolute-paths mode with sync=3Dfull, the target will have the backing chain of the source. This is something that this patch fixes. In fact, I think if you do drive-mirror in existing mode or blockdev-mirror and the target image does not have a backing file (whatever sync mode you have used), the same will happen. Max > bdrv_open_backing_file() is used because what we want to do is to > "undo" the BDRV_O_NO_BACKING flag used by qmp_drive_mirror. >=20 > If the contents change under the guest feet, it's the layers above > QEMU that have screwed up. >=20 > Paolo >=20 --jHjO4lK6hBtNs4Ror50jOPK2UbEFWoruF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXWC5OAAoJEDuxQgLoOKytOVQH/ifKscB/TtijO2elj32KlpZe nLU1lSOFOlct0YPJylvA19KsnZvR6snxsfV6O9BwFsDalAtJAoCZ84kSbhxDaFH1 kD0DNXqWbaMnnVof7oIMDYPj8JbTjyINSlVEio8jViC+B1vV7Sb0ZgYugRzRWKEg mCXkGOYBBNU24tHj8Z1JqJaQct0q7YSYUkigj2xRYUF2e09Csiwzlo5yQ9oEDgOb rWYNaV9GvkbJAkmZMsg7C89m56IqRqrBfIYNK0UwCGdg+F3gaAxzQbxeRzNpcB3J 0c/Wr4A9zIdhD0FVriiT+pjnw/OE8WV519aD0y72m00GKs1S+imiqlc9lkYvYc0= =f6KE -----END PGP SIGNATURE----- --jHjO4lK6hBtNs4Ror50jOPK2UbEFWoruF--