qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v7 03/24] block: Release dirty bitmaps in bdrv_c


From: Fam Zheng
Subject: Re: [Qemu-devel] [PATCH v7 03/24] block: Release dirty bitmaps in bdrv_close()
Date: Mon, 16 Nov 2015 09:27:46 +0800
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, 11/13 17:49, John Snow wrote:
> 
> 
> 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.
> 

Yes, I was not saying we should expecting user to do that manually, but it
would be good to be clear about different types of instances in the code.

For now, it's unlikely a problem.

Fam



reply via email to

[Prev in Thread] Current Thread [Next in Thread]