From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44334) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XLqiS-0003ON-LU for qemu-devel@nongnu.org; Mon, 25 Aug 2014 05:37:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XLqiM-0000Xp-GT for qemu-devel@nongnu.org; Mon, 25 Aug 2014 05:37:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45737) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XLqiM-0000Xl-7R for qemu-devel@nongnu.org; Mon, 25 Aug 2014 05:37:26 -0400 Date: Mon, 25 Aug 2014 17:37:37 +0800 From: Fam Zheng Message-ID: <20140825093737.GA25434@T430.nay.redhat.com> References: <1408723870-7826-1-git-send-email-benoit.canet@nodalink.com> <1408723870-7826-2-git-send-email-benoit.canet@nodalink.com> <20140825060424.GA17482@T430.nay.redhat.com> <20140825090611.GA18202@nodalink.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20140825090611.GA18202@nodalink.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] block: Make op blockers recursive List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?iso-8859-1?Q?Beno=EEt?= Canet Cc: kwolf@redhat.com, jcody@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com On Mon, 08/25 09:06, Beno=EEt Canet wrote: > On Mon, Aug 25, 2014 at 02:04:24PM +0800, Fam Zheng wrote: > > On Fri, 08/22 18:11, Beno=EEt Canet wrote: > > > Since the block layer code is starting to modify the BDS graph righ= t 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 ne= at way to > > > achieve this task. > > >=20 > > > This patch also takes care of modifying the op blockers users. > >=20 > > Is this going to replace backing_blocker? > >=20 > > I think it is too general an approach to control the operation proper= ly, > > 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. > >=20 > > So could you explain in which cases is the recursive blocking/unblock= ing > > useful? >=20 > It's designed for the new crop of block operations operating on BDS loc= ated in > the middle of the backing chain: Jeff's patches, intermediate live stre= aming 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 suppo= sed to be protected by backing_blocker. Could you be more specific? 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, e= tc. They should be protected as well. But it seems to me that these are not recursive association, so we don't = need to apply the blocker recursively. Shouldn't it be enough to only block bs= ->file when assigning this pointer, and unblock it when unassigning? I'm not trying to push back this series. I am asking just because that my understanding to the question still needs some forging. Fam