[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] block: Make op blockers recursive
From: |
Benoît Canet |
Subject: |
Re: [Qemu-devel] [PATCH] block: Make op blockers recursive |
Date: |
Wed, 10 Sep 2014 15:49:38 +0000 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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
>