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: Kevin Wolf
Subject: Re: x-blockdev-reopen & block-dirty-bitmaps
Date: Mon, 17 Feb 2020 11:58:18 +0100
User-agent: Mutt/1.12.1 (2019-06-15)

Am 17.02.2020 um 11:28 hat Alberto Garcia geschrieben:
> On Fri 14 Feb 2020 07:54:36 PM CET, John Snow wrote:
> 
> > Probably a loaded question, but:
> >
> > - What's needed to make the interface stable?
> > - Are there known problem points?
> 
> 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);

This is bdrv_reopen_commit(), so we can't return an error, but
bdrv_set_backing_hd() can potentially fail if an AioContext switch is
involved. If we move it already in bdrv_reopen_prepare(), it could work,
though.

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...)

Kevin




reply via email to

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