All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fam Zheng <famz@redhat.com>
To: "Benoît Canet" <benoit.canet@nodalink.com>
Cc: kwolf@redhat.com, jcody@redhat.com, qemu-devel@nongnu.org,
	stefanha@redhat.com
Subject: Re: [Qemu-devel] [PATCH] block: Make op blockers recursive
Date: Tue, 26 Aug 2014 12:42:04 +0800	[thread overview]
Message-ID: <20140826044204.GB2517@T430.nay.redhat.com> (raw)
In-Reply-To: <20140825121219.GB18202@nodalink.com>

On Mon, 08/25 12:12, Benoît Canet wrote:
> On Mon, Aug 25, 2014 at 05:37:37PM +0800, Fam Zheng wrote:
> > On Mon, 08/25 09:06, Benoît Canet wrote:
> > > On Mon, Aug 25, 2014 at 02:04:24PM +0800, Fam Zheng wrote:
> > > > On Fri, 08/22 18:11, Benoît Canet wrote:
> > > > > Since the block layer code is starting to modify the BDS graph right in the
> > > > > middle of BDS chains (block-mirror's replace parameter for example) QEMU needs
> > > > > to properly block and unblock whole BDS subtrees; recursion is a neat way to
> > > > > achieve this task.
> > > > > 
> > > > > This patch also takes care of modifying the op blockers users.
> > > > 
> > > > Is this going to replace backing_blocker?
> > > > 
> > > > I think it is too general an approach to control the operation properly,
> > > > because the op blocker may not work in the same way for all types of BDS
> > > > connections.  In other words, the choosing of op blockers are likely
> > > > conditional on graph edge types, that's why backing_blocker was added here. For
> > > > example, A VMDK extent connection will probably need a different set of
> > > > blockers than bs->file connection.
> > > > 
> > > > So could you explain in which cases is the recursive blocking/unblocking
> > > > useful?
> > > 
> > > It's designed for the new crop of block operations operating on BDS located in
> > > the middle of the backing chain: Jeff's patches, intermediate live streaming or
> > > intermediate mirroring.
> > > Recursively blocking BDS allows to do these operations safely.
> > 
> > Sorry I may be slow on this, but it's still not clear to me.
> > 
> > That doesn't immediately show how backing_blocker doesn't work. These
> > operations are in the category of operations that update graph topology,
> > meaning that they drop, add or swap some nodes in the middle of the chain. It
> > is not safe because there are used by the other nodes, but they are supposed to
> > be protected by backing_blocker. Could you be more specific?
> 
> I don't know particularly about the backing blocker case.
> 
> > 
> > I can think of something more than backing_hd: there are also link types other
> > than backing_hd, for example ->file, (vmdk)->extents or (quorum)->qcrs, etc.
> > They should be protected as well.
> 
> This patch takes cares of recursing everywhere.
> 
> I can give you an example for quorum.
> 
> If a streaming operation is running on a quorum block backend the recursive
> blocking will help to block any operation done directly on any of the children.

At what points should block layer recursively block/unblock the operations in
this quorum case?

Fam

> 
> It's usefull since we introduced drive-mirror replace which will replace an arbitrary
> node of a quorum at the end of the mirroring operation.

  reply	other threads:[~2014-08-26  4:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-22 16:11 [Qemu-devel] [PATCH] Implement recursive op blockers Benoît Canet
2014-08-22 16:11 ` [Qemu-devel] [PATCH] block: Make op blockers recursive Benoît Canet
2014-08-25  6:04   ` Fam Zheng
2014-08-25  9:06     ` Benoît Canet
2014-08-25  9:37       ` Fam Zheng
2014-08-25 12:12         ` Benoît Canet
2014-08-26  4:42           ` Fam Zheng [this message]
2014-08-26  6:45             ` Benoît Canet
2014-09-04 20:42               ` Stefan Hajnoczi
2014-09-10  8:54                 ` Fam Zheng
2014-09-10 14:18                   ` Benoît Canet
2014-09-10 15:14                   ` Eric Blake
2014-09-10 15:49                     ` Benoît Canet
2014-09-11 11:22                       ` Kevin Wolf
2014-09-11  0:50                     ` Fam Zheng
2014-09-09 11:56   ` Kevin Wolf
2014-09-09 14:28     ` Benoît Canet
2014-09-12  3:48       ` Fam Zheng
2014-09-15 15:17         ` Benoît Canet
2014-09-18  2:57           ` Fam Zheng
2014-09-22 12:33             ` Benoît Canet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140826044204.GB2517@T430.nay.redhat.com \
    --to=famz@redhat.com \
    --cc=benoit.canet@nodalink.com \
    --cc=jcody@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.