From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57091) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7SSO-0004Le-Ve for qemu-devel@nongnu.org; Tue, 23 Jun 2015 13:58:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z7SSK-0001zE-QN for qemu-devel@nongnu.org; Tue, 23 Jun 2015 13:58:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48156) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z7SSK-0001z9-Ka for qemu-devel@nongnu.org; Tue, 23 Jun 2015 13:57:56 -0400 Message-ID: <55899E23.6080707@redhat.com> Date: Tue, 23 Jun 2015 13:57:55 -0400 From: John Snow MIME-Version: 1.0 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> In-Reply-To: <20150615144237.GH9410@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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: Stefan Hajnoczi Cc: kwolf@redhat.com, Vladimir Sementsov-Ogievskiy , qemu-devel@nongnu.org, Vladimir Sementsov-Ogievskiy , den@openvz.org, pbonzini@redhat.com 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 I still don't follow you, actually. 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. Right? Am I fatally misunderstanding the situation?