[Top][All Lists]

[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 14:57:13 +0100
User-agent: Mutt/1.12.1 (2019-06-15)

Am 17.02.2020 um 14:03 hat Alberto Garcia geschrieben:
> 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.

Yes, I'm sure we'll have to resort to QAPI features here and there to
make things introspectable. But the more options you can change from the
start, the less we'll need to do this.


reply via email to

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