From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38634) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XM8Zx-0003nF-Bu for qemu-devel@nongnu.org; Tue, 26 Aug 2014 00:42:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XM8Zr-0006Ra-7l for qemu-devel@nongnu.org; Tue, 26 Aug 2014 00:41:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:31099) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XM8Zr-0006RT-0C for qemu-devel@nongnu.org; Tue, 26 Aug 2014 00:41:51 -0400 Date: Tue, 26 Aug 2014 12:42:04 +0800 From: Fam Zheng Message-ID: <20140826044204.GB2517@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> <20140825093737.GA25434@T430.nay.redhat.com> <20140825121219.GB18202@nodalink.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20140825121219.GB18202@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 12:12, Beno=EEt Canet wrote: > On Mon, Aug 25, 2014 at 05:37:37PM +0800, Fam Zheng wrote: > > 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 = right in the > > > > > middle of BDS chains (block-mirror's replace parameter for exam= ple) QEMU needs > > > > > to properly block and unblock whole BDS subtrees; recursion is = a neat 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 pr= operly, > > > > 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 lik= ely > > > > conditional on graph edge types, that's why backing_blocker was a= dded 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/unb= locking > > > > useful? > > >=20 > > > 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. > >=20 > > Sorry I may be slow on this, but it's still not clear to me. > >=20 > > That doesn't immediately show how backing_blocker doesn't work. These > > operations are in the category of operations that update graph topolo= gy, > > meaning that they drop, add or swap some nodes in the middle of the c= hain. It > > is not safe because there are used by the other nodes, but they are s= upposed to > > be protected by backing_blocker. Could you be more specific? >=20 > I don't know particularly about the backing blocker case. >=20 > >=20 > > I can think of something more than backing_hd: there are also link ty= pes other > > than backing_hd, for example ->file, (vmdk)->extents or (quorum)->qcr= s, etc. > > They should be protected as well. >=20 > This patch takes cares of recursing everywhere. >=20 > I can give you an example for quorum. >=20 > If a streaming operation is running on a quorum block backend the recur= sive > blocking will help to block any operation done directly on any of the c= hildren. At what points should block layer recursively block/unblock the operation= s in this quorum case? Fam >=20 > It's usefull since we introduced drive-mirror replace which will replac= e an arbitrary > node of a quorum at the end of the mirroring operation.