From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59985) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zgf54-0004dK-K2 for qemu-devel@nongnu.org; Mon, 28 Sep 2015 16:31:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zgf50-0006ka-Jc for qemu-devel@nongnu.org; Mon, 28 Sep 2015 16:31:26 -0400 References: <56094B0F.7030900@redhat.com> From: Eric Blake Message-ID: <5609A38F.1070405@redhat.com> Date: Mon, 28 Sep 2015 14:31:11 -0600 MIME-Version: 1.0 In-Reply-To: <56094B0F.7030900@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HmdS1QJKbeC211CBnH62i4SCFsmKdnob1" 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: Paolo Bonzini , Jeff Cody , qemu-devel@nongnu.org Cc: kwolf@redhat.com, stefanha@redhat.com, qemu-block@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HmdS1QJKbeC211CBnH62i4SCFsmKdnob1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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". 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. 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). I think Paolo is right: we care about zeroing unallocated sectors for sync =3D=3D 'full', regardless of whether mode =3D=3D 'existing'. 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. >=20 > The reasons are: >=20 > 1) with sync !=3D "full", unallocated target sectors should remain > unallocated on the destination because they are supposed to point to th= e > backing file. >=20 > 2) even with mode =3D=3D "existing" you expect the data to be consisten= t at > the end of the mirroring >=20 > Paolo >=20 >=20 --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --HmdS1QJKbeC211CBnH62i4SCFsmKdnob1 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 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJWCaOPAAoJEKeha0olJ0Nq50wH/A9iioFcNtgRLwiKV8S5cig4 LjisK6oAfajftNkg23y2HKSv7gquCaZVO8on7Lm3NRK/wnnDWCb4C92vBT/pUzBA ZI/gaa4/DY3WxZOtqvbF58qylDwg96Vri4E+1BUx0BUWQPo4IEjgOmzRCGzF1jdS D7VEWYg7hwDH3I8AAYEh/vA9+EUK9FHYf8Zaz86Itdi9kYVR6ahN574NsRuo9b/8 vnJCfYlRTJaL7li/u1uglL9iKy7Rf21kUJv3cw2jIuUJ2vvcjGUohQiXHh859d90 SuQK19u+lF+Ex3aDy5tzZD1KSnkej92NBoYMqpMR18z8fiYLLqYRygTcOvwHXtI= =bvGC -----END PGP SIGNATURE----- --HmdS1QJKbeC211CBnH62i4SCFsmKdnob1--