Re: [Qemu-devel] [PATCH] block: Make op blockers recursive

[Fam Zheng]

On Wed, 09/10 09:14, Eric Blake wrote:
> On 09/10/2014 02:54 AM, Fam Zheng wrote:
> 
> >> Let's think of a situation that recursive blockers protect but
> >> backing_blocker does not:
> >>
> >> a <- b <- c <- d
> >>
> >> c is the backing file and is therefore protected by the op blocker.
> >>
> >> The block-commit command works with node-names, however, so we can
> >> manipulate any nodes in the graph, not just the topmost one.  Try this:
> >>
> >> block-commit d
> >> block-commit b
> >>
> >> I haven't checked yet but I suspect it will launch two block-commit jobs
> >> on the same partial chain (that's a bad thing because it can lead to
> >> corruption).
> > 
> > 1) Does block-commit work with node-names already? In other words, is
> >    block-commit b possible now? I only see drive-mirror works with it, but 
> > not
> >    drive-backup, block-mirror or block-commit.
> 
> IIRC, Jeff Cody proposed patches for qemu 2.1 that would have done this,
> but we dropped them for that release in order to get the recursive
> blockers sorted out first.
> 
>  >
> > 2) Regardless of the answer to 1), I think we could use a similar approach 
> > as
> >    drive-backup here: split BLOCK_OP_TYPE_COMMIT to
> >    BLOCK_OP_TYPE_COMMIT_{SOURCE,TARGET}, and only unblock
> >    BLOCK_OP_TYPE_COMMIT_TARGET in bdrv_set_backing_hd.
> 
> In that earlier thread, Jeff had some ideas that it is not so much the
> operation name that should be the blocker, but the lower-level action(s)
> implied by each operation (read metadata, write metadata, read image,
> write image)
> 

Yes, that is a good idea.

I had an open question back in that thread, which was whether we care about any
other operation types at all - I think the only disruptive operations here are
those that call bdrv_swap(). Any others?

Fam