From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54464) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgqRT-000697-Dw for qemu-devel@nongnu.org; Tue, 29 Sep 2015 04:39:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZgqRS-0002C6-FO for qemu-devel@nongnu.org; Tue, 29 Sep 2015 04:39:19 -0400 Date: Tue, 29 Sep 2015 10:39:14 +0200 From: Kevin Wolf Message-ID: <20150929083914.GC3930@noname.str.redhat.com> References: <56097990.7040007@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V0207lvV8h4k8FAm" Content-Disposition: inline In-Reply-To: <56097990.7040007@redhat.com> Subject: Re: [Qemu-devel] [Qemu-block] [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: Max Reitz Cc: Jeff Cody , qemu-block@nongnu.org, qemu-devel@nongnu.org, stefanha@redhat.com --V0207lvV8h4k8FAm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 28.09.2015 um 19:32 hat Max Reitz geschrieben: > On 28.09.2015 05:29, Jeff Cody wrote: > > During mirror, if the target device does not have support zero > > initialization, a mirror may result in a corrupt image. > >=20 > > For instance, on mirror to a host device with format =3D raw, whatever > > random data is on the target device will still be there for unallocated > > sectors. > >=20 > > This is because during the mirror, we set the dirty bitmap to copy only > > sectors allocated above 'base'. In the case of target devices where we > > cannot assume unallocated sectors will be read as zeroes, we need to > > explicitely zero out this data. > >=20 > > In order to avoid zeroing out all sectors of the target device prior to > > mirroring, we do zeroing as part of the block job. A second dirty > > bitmap cache is created, to track sectors that are unallocated above > > 'base'. These sectors are then checked for status of BDRV_BLOCK_ZERO > > on the target - if they are not, then zeroes are explicitly written. > >=20 > > This only occurs under two conditions: > >=20 > > 1. 'mode' !=3D "existing" > > 2. bdrv_has_zero_init(target) =3D=3D NULL > >=20 > > We perform the mirroring through mirror_iteration() as before, except > > in two passes. If the above two conditions are met, the first pass > > is using the bitmap tracking unallocated sectors, to write the needed > > zeroes. Then, the second pass is performed, to mirror the actual data > > as before. > >=20 > > If the above two conditions are not met, then the first pass is skipped, > > and only the second pass (the one with the actual data) is performed. > >=20 > > Signed-off-by: Jeff Cody > > @@ -737,6 +787,7 @@ static void mirror_start_job(BlockDriverState *bs, = BlockDriverState *target, > > return; > > } > > =20 > > + s->zero_unallocated =3D !existing && !bdrv_has_zero_init(target); >=20 > I think this should be set only if we're doing a full mirror operation. > For instance, I could do a none, top or incremental mirror to a new > qcow2 file, which would give it a backing file, obviously. You're lucky > in that qcow2 claims to always have zero initialization, when this is in > fact not true (someone's ought to fix that...): With a backing file, an > overlay file just cannot have zero initialization, it's impossible > (well, unless the backing file is completely zero). bdrv_has_zero_init() takes care of that, in theory. The "problem" here is that the target is opened with BDRV_O_NO_BACKING, so the block layer doesn't consider this an image with a backing file. Is there anything better than bs->backing_hd that we could check? Kevin --V0207lvV8h4k8FAm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJWCk4yAAoJEH8JsnLIjy/W0fMP/RxUu+qOrAgDzBnF/q+R7Y5L Cbt+Npx8EDKQEopvHexAqrl3SGHfUvmRXXYk5qwHPWzuToBGPs5FIPw8MUE5bRal 7T7e7+fQIotWRPozNm9qhpObI+T1G1+3R5vl69z1xhEAtBwyG5RCOsLIXU6eTNfa hYEEVvpKGUVcl/bi8wftO5XmV6g1YsI+sG5mbrTWZFThEC4Biq9wjPpzpIO0WaZC eGE3WFs3kRA7EQ3PoNIU7eH69Saa5ChltRIX2qB3KABtr1PdvYhu7J2MG0ZNatGv Rd+unin/d9884yZn5llsmyIPUf3ZwcBAaFPT1QA3+OesWZ4T6dkRE2WsssU2PtW7 Vt1MRM2CTNl1/cZpEjyq6xwhJumYGbONd6XMtt5LuvN41skrp6AQwZjp7f9oFxLa 9TjiF4EfHJDeCcjvwrN4mxLV6kwTI3eTQ7tNRgW6RFRO4tdtzO43hsEvy40Kyimb 8sX2ehZHnyWdpDH4NjbuO6WfaYh1o+KzSBfNCjTmoN3+b7KZIGCcrGqHT9TIDtz9 y5w/EbtkNuYazqEQc7B+CVkfBKD/sD5Qh8UIxe9thxMbw5UpNJ9xdzsSFJ2g15En Dm1aSls1L7KBR1KAXfeFBol7bplt0DU/0oz9eR/kGzVUn/TRALga0R4i3whZYiuj U/UUpsz6uLs3PRIT3PdV =TiWQ -----END PGP SIGNATURE----- --V0207lvV8h4k8FAm--