[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [PATCH 01/13] block: Allow freezing BdrvChild links
From: |
Alberto Garcia |
Subject: |
Re: [Qemu-block] [PATCH 01/13] block: Allow freezing BdrvChild links |
Date: |
Mon, 18 Feb 2019 14:35:30 +0100 |
User-agent: |
Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (i586-pc-linux-gnu) |
On Thu 14 Feb 2019 04:52:52 PM CET, Kevin Wolf wrote:
> Am 14.02.2019 um 15:13 hat Alberto Garcia geschrieben:
>> On Tue 12 Feb 2019 03:47:47 PM CET, Kevin Wolf wrote:
>> > Am 17.01.2019 um 16:33 hat Alberto Garcia geschrieben:
>> >> @@ -3861,6 +3923,10 @@ int bdrv_drop_intermediate(BlockDriverState *top,
>> >> BlockDriverState *base,
>> >> goto exit;
>> >> }
>> >>
>> >> + if (bdrv_is_backing_chain_frozen(top, base, NULL)) {
>> >> + goto exit;
>> >> + }
>> >> +
>> >> /* If 'base' recursively inherits from 'top' then we should set
>> >> * base->inherits_from to top->inherits_from after 'top' and all
>> >> * other intermediate nodes have been dropped.
>> >
>> > bdrv_drop_intermediate() doesn't change the links between in the chain
>> > between top and base, but the links between the parents of top and top
>> > are changed to point to base instead.
>> >
>> > I think this is checking the wrong thing.
>>
>> You're right, those links should be checked.
>>
>> On the other hand it does remove all references from top's parents to
>> top, so in the general case it will end up deleting all intermediate
>> notes, and their backing links with them. So I think we still need that
>> check.
>
> That begs the question if removing a frozen child link should be
> forbideen even when it's because the parent goes away. It don't think
> there is a good reason to check this - who else than the removed
> parent could be interested in keeping it frozen?
>
> In fact, this means that the parent forgot to unfreeze its child
> before going away, which shouldn't happen. So I guess bdrv_close()
> could just assert that this is not the case for any children?
That actually sounds like a good solution.
Berto