From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36948) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7h9C-0000yY-O8 for qemu-devel@nongnu.org; Wed, 24 Jun 2015 05:39:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7h97-0003qU-Ot for qemu-devel@nongnu.org; Wed, 24 Jun 2015 05:39:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35819) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7h97-0003q4-K0 for qemu-devel@nongnu.org; Wed, 24 Jun 2015 05:39:05 -0400 Date: Wed, 24 Jun 2015 10:39:03 +0100 From: Stefan Hajnoczi Message-ID: <20150624093903.GB7454@stefanha-thinkpad.redhat.com> References: <1433776886-27239-1-git-send-email-vsementsov@virtuozzo.com> <1433776886-27239-3-git-send-email-vsementsov@virtuozzo.com> <20150610143041.GE2430@stefanha-thinkpad.home> <557B2CC9.5020309@redhat.com> <20150615144237.GH9410@stefanha-thinkpad.redhat.com> <55899E23.6080707@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kXdP64Ggrk/fb43R" Content-Disposition: inline In-Reply-To: <55899E23.6080707@redhat.com> Subject: Re: [Qemu-devel] [PATCH 2/8] qcow2: add dirty-bitmaps feature List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow Cc: kwolf@redhat.com, Vladimir Sementsov-Ogievskiy , qemu-devel@nongnu.org, Vladimir Sementsov-Ogievskiy , den@openvz.org, pbonzini@redhat.com --kXdP64Ggrk/fb43R Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 23, 2015 at 01:57:55PM -0400, John Snow wrote: > On 06/15/2015 10:42 AM, Stefan Hajnoczi wrote: > > On Fri, Jun 12, 2015 at 03:02:33PM -0400, John Snow wrote: > >> > >> > >> On 06/10/2015 10:30 AM, Stefan Hajnoczi wrote: > >>> On Mon, Jun 08, 2015 at 06:21:20PM +0300, Vladimir Sementsov-Ogievski= y wrote: > >>> > >>> I noticed a corner case, it's probably not a problem in practice: > >>> > >>> Since the dirty bitmap is stored with the help of a BlockDriverState > >>> (and its bs->file), it's possible that writing the bitmap will cause > >>> bits in the bitmap to be dirtied! > >>> > >> > >> But since it's metadata and not stored within a disk sector, can this > >> actually happen? Do you have an example of a scenario where this might > >> come up? > >=20 > > The persistent dirty bitmap for bs->file is storeed in the qcow2 BDS. > > This results in recursion. > >=20 > > This is a misconfiguration but I just want to understand what happens > > when someone does this by mistake. > >=20 > > Stefan > >=20 >=20 > I still don't follow you, actually. >=20 > The dirty bitmap only tracks changed virtual disk sectors, not actual > file sectors, right? Writing a bitmap that describes foo.qcow2 to > foo.qcow2 won't dirty bitmaps, it's an out-of-channel write as far as > the bitmap is concerned. >=20 > Right? Am I fatally misunderstanding the situation? There is no out-of-channel for bs->file. The bs->file raw-posix image file includes the bs qcow2 sectors that hold the dirty bitmap. This is a corner case and I don't think any valid configuration would hit it. Stefan --kXdP64Ggrk/fb43R Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVinq3AAoJEJykq7OBq3PIT64IAJWhtkJkj7Uvp7/gRNW9bGka e6pcB8rOqU6yP9CVM+pkFIIUVsJzkIz9mO64W5mgTgceEhUSndqBiN9Qub54/koF U1OdI9PCHQlRDJcWNMJQpujS6XnAhtVhKGIEhmUGR/sZ7NtR0oWWeXCbwpgspZqf H6n7kN8Hi3XFD0cioa96cX97kQrWslIRTNMD6GbGBsHJYlcsD2STtn9KyyHCphd4 yn1kF+pDJgL1MtyHpJdD6W4yGiPLq0sdJFvFL6Nq4fAr8/0Lcv27pBal9OjtVEAJ H3JTirWV8mwXcYeF3WGCo88T8KSNXJMtub8///zln2RkAX66JC8B7k5ZDhSJUy4= =KYxU -----END PGP SIGNATURE----- --kXdP64Ggrk/fb43R--