qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 2/2] blockjob: use blk_new_pinned in block_jo


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH v2 2/2] blockjob: use blk_new_pinned in block_job_create
Date: Thu, 6 Jun 2019 12:05:10 +0200
User-agent: Mutt/1.11.3 (2019-02-01)

Am 05.06.2019 um 19:16 hat Vladimir Sementsov-Ogievskiy geschrieben:
> 05.06.2019 20:11, Kevin Wolf wrote:
> > Am 05.06.2019 um 14:32 hat Vladimir Sementsov-Ogievskiy geschrieben:
> >> child_role job already has .stay_at_node=true, so on bdrv_replace_node
> >> operation these child are unchanged. Make block job blk behave in same
> >> manner, to avoid inconsistent intermediate graph states and workarounds
> >> like in mirror.
> >>
> >> Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
> > 
> > This feels dangerous. It does what you want it to do if the only graph
> > change below the BlockBackend is the one in mirror_exit_common. But the
> > user could also take a snapshot, or in the future hopefully insert a
> > filter node, and you would then want the BlockBackend to move.
> > 
> > To be honest, even BdrvChildRole.stay_at_node is a bit of a hack. But at
> > least it's only used for permissions and not for the actual data flow.
> 
> Hmm. Than, may be just add a parameter to bdrv_replace_node, which parents
> to ignore? Would it work?

I would have to think a bit more about it, but it does sound safer.

Or we take a step back and ask why it's even a problem for the mirror
block job if the BlockBackend is moved to a different node. The main
reason I see is because of bs->job that is set for the root node of the
BlockBackend and needs to be unset for the same node.

Maybe we can just finally get rid of bs->job? It doesn't have many users
any more.

Kevin



reply via email to

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