From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51235) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxNAU-0003uP-0N for qemu-devel@nongnu.org; Fri, 13 Nov 2015 17:50:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZxNAT-0004uP-3R for qemu-devel@nongnu.org; Fri, 13 Nov 2015 17:50:05 -0500 References: <1447108773-6836-1-git-send-email-mreitz@redhat.com> <1447108773-6836-4-git-send-email-mreitz@redhat.com> <20151112062349.GC4082@ad.usersys.redhat.com> From: John Snow Message-ID: <56466916.6040300@redhat.com> Date: Fri, 13 Nov 2015 17:49:58 -0500 MIME-Version: 1.0 In-Reply-To: <20151112062349.GC4082@ad.usersys.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v7 03/24] block: Release dirty bitmaps in bdrv_close() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng , Max Reitz Cc: Kevin Wolf , Alberto Garcia , qemu-block@nongnu.org, Markus Armbruster , qemu-devel@nongnu.org, Stefan Hajnoczi , Paolo Bonzini On 11/12/2015 01:23 AM, Fam Zheng wrote: > On Mon, 11/09 23:39, Max Reitz wrote: >> bdrv_delete() is not very happy about deleting BlockDriverStates with >> dirty bitmaps still attached to them. In the past, we got around that >> very easily by relying on bdrv_close_all() bypassing bdrv_delete(), and >> bdrv_close() simply ignoring that condition. We should fix that by >> releasing all dirty bitmaps in bdrv_close() and drop the assertion in >> bdrv_delete(). > > What bitmaps are attached when bdrv_close() is called? The ones created from > the monitor should probably be removed by the monitor, and the internal ones > like in migration and block jobs should probably be removed by stopping the > respective job. > > Fam > Well in this case at least it appears we are still asserting that the BDS has no job attached, so it shouldn't have any internal bitmaps weighing it down, which just leaves the ones created by the QMP interface. How important is it that we ask the user to remove all of those bitmaps themselves? It might become more important in the future when persistence is an option and we go to close a transient bitmap -- but persistent bitmaps I am sure it will be safe to just close out and flush to disk. --js