qemu-block
[Top][All Lists]
Advanced

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

Re: x-blockdev-reopen & block-dirty-bitmaps


From: Alberto Garcia
Subject: Re: x-blockdev-reopen & block-dirty-bitmaps
Date: Mon, 17 Feb 2020 14:03:56 +0100
User-agent: Notmuch/0.18.2 (http://notmuchmail.org) Emacs/24.4.1 (i586-pc-linux-gnu)

On Mon 17 Feb 2020 11:58:18 AM CET, Kevin Wolf wrote:
>> As far as I'm aware there's nothing needed to make x-blockdev-reopen
>> stable. It was just marked experimental because it's a relatively
>> complex operation and I wanted to have some margin to detect bugs or
>> other possible problems.
>
> Maybe some more test cases for potentially problematic things like
> attaching a backing file node that is in a different AioContext than
> the new parent. But I think the recent AioContext management fixes
> should have taken care of this. (Actually, bdrv_reopen_parse_backing()
> still forbids this case and has a "TODO" comment there.)
>
> Hm... In fact I guess it would still be broken:
>
>     bdrv_set_backing_hd(bs, reopen_state->new_backing_bs,
>     &error_abort);

I can give that a try and add a new test case if necessary.

> Another thing that we probably want to add is changing bs->file,
> specifically in order to insert or remove filter nodes. If we don't do
> this before marking blockdev-reopen stable, introspection wouldn't be
> able to detect when we later add it. (We have QAPI features now to
> work around this, but...)

I'm not sure if introspection can track all the changes in this feature,
though. The list of runtime options that can be modified for each driver
can change as we add support to new ones, as can change the list of
drivers that allow reopening.

Berto



reply via email to

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