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

["Benoît Canet" <benoit.canet@nodalink.com>]

On Wed, Sep 10, 2014 at 09:14:35AM -0600, 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)

Does it mean I should pause this current series and task switch to another
infrastucture task ?
I could switch to the block I/O accouting work.

What does the other developpers and maintainers think about it ?

> 
> -- 
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>