From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41003) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zgpzo-0000BV-MI for qemu-devel@nongnu.org; Tue, 29 Sep 2015 04:10:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zgpzn-0006Vg-K2 for qemu-devel@nongnu.org; Tue, 29 Sep 2015 04:10:44 -0400 Date: Tue, 29 Sep 2015 10:10:34 +0200 From: Kevin Wolf Message-ID: <20150929081034.GA3930@noname.str.redhat.com> References: <56094B0F.7030900@redhat.com> <5609A38F.1070405@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline In-Reply-To: <5609A38F.1070405@redhat.com> Subject: Re: [Qemu-devel] [PATCH 3/3] block: mirror - zero unallocated target sectors when zero init not present List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Paolo Bonzini , Jeff Cody , stefanha@redhat.com, qemu-devel@nongnu.org, qemu-block@nongnu.org --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 28.09.2015 um 22:31 hat Eric Blake geschrieben: > On 09/28/2015 08:13 AM, Paolo Bonzini wrote: > >=20 > >=20 > > On 28/09/2015 05:29, Jeff Cody wrote: > >> This only occurs under two conditions: > >> > >> 1. 'mode' !=3D "existing" > >> 2. bdrv_has_zero_init(target) =3D=3D NULL > >> > >=20 > > I'm not sure if mode !=3D "existing" actually matters. I think what > > actually matters is sync =3D=3D "full". >=20 > When mode =3D=3D 'existing' for a shallow mirror (sync !=3D 'full'), that= is > the caller stating that the guest-visible contents of the destination > match the guest-visible contents of the backing image. The only sectors > to be copied are those that differ from the backing file, and we should > not be zeroing unrelated sectors because the user has already promised > they have the same guest-visible content as the backing image would repor= t. Where is this promise documented? I wasn't aware of it and can't seem to find it in the QAPI documentation of drive-mirror. > When mode =3D=3D 'existing' for a full mirror (sync =3D=3D 'full'), that = is the > caller stating that they want every single sector of the destination > written to hold the current state of the source (of course, allowing for > optimizations such as skipping the write where the contents will read > back the same as if the write had been performed). >=20 > I think Paolo is right: we care about zeroing unallocated sectors for > sync =3D=3D 'full', regardless of whether mode =3D=3D 'existing'. I agree. > I also think the reason Jeff confused it for mode =3D=3D 'existing' is th= at > the other modes let qemu create the file, but qemu does not create block > devices (the only way to mirror to a block device is via mode =3D=3D > 'existing'), and it is primarily block devices where zero init is not > guaranteed. 'qemu-img create' works on block devices (even though for raw it doesn't do more than checking if it's large enough; but for qcow2, it's obvious that it's necessary), so I'm pretty sure that mode !=3D 'existing' works on them as well. Kevin --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJWCkd5AAoJEH8JsnLIjy/WeFQP/AzAoke7eiDcAU14ZSmBey+s W7B6UEZHoG0UV8v59cOTO5Nspy+lCycVc+AEi8JdgEvdH23SAC26drceynOm9okT 7X0rmzqtWfvVeu6WKrgbX0A3gx8iXeP2B9TbtUqNmFOP37rdIUTZ1d5Kx3uPUg2w 6xnfaOoSE7nLQj2L2jv8RzkE04t/uXXlMyN8/U1m19jYZlWQfAKxHwM0o3r3zYiB Y60HeQfUYEyq9f20hulkp0xG2JIx5djqNym4ycdMr2HZtrcDOyfWg76jHR7Sz/I/ Q2f9jnXnJga3Za7XJVDCFVNcNkADEEclPK7VPROBcZ5vzG+UOUoAJavYgNmqsb9Q OP0N2VDU5zB/AJMQ6+HiHO8DfYEgdtOoL/OY/KDq1BZ31ersE9PJLDf8+AzX9VJd b9cz66d+zjz2OnWQUzIau+AmjLWhg6DEpZ761uE2yw2hVDmlgHcOLNtczE57C18d JNVVXcOOmNWpS8JcYcqBv/CbS14h+GjUFBCftPJrl8AzgEeO2L5+YdLhsjp/Lx4D o9p33dgtv/wocM1wtwub+3arCHequY85jwSl97YJML+SedyaSQbWLdBSov1bAFlK TS/PYBrB/RdnY1tAgpWqbnmcoJ3C5nZkujAUZAVauIVuRwaMAuLRHerBAb4HWFYB 4T/inJQonFgmaUv7PqlN =cuN+ -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N--