qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [Qemu-devel] [PATCH v7 03/24] block: Release dirty bitm


From: John Snow
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH v7 03/24] block: Release dirty bitmaps in bdrv_close()
Date: Mon, 16 Nov 2015 12:07:44 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0


On 11/15/2015 08:27 PM, Fam Zheng wrote:
> 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
> 

OK, just pointing out that I think it's unlikely we have any internal
bitmaps at this point since we assert that we have no jobs.

We can actually test this, since internal bitmaps are anonymous and
user-created ones must always have a name.

Tangent question: If a user closes a BDS node with a transient bitmap
attached, should we take any special action?

i.e.; do we offer the user a last chance to save the bitmap somewhere,
or do we just do what we were asked and hope the user is competent?

(I assume: No, we let the user shoot themselves in the foot if they want
to, but I wanted to ask the question.)

--js




reply via email to

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