From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55034) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XMAW2-0007Cg-Fg for qemu-devel@nongnu.org; Tue, 26 Aug 2014 02:46:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XMAVw-0005yH-5Y for qemu-devel@nongnu.org; Tue, 26 Aug 2014 02:46:02 -0400 Received: from dew.nodalink.com ([95.130.14.197]:40732) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XMAVv-0005y8-SI for qemu-devel@nongnu.org; Tue, 26 Aug 2014 02:45:56 -0400 Date: Tue, 26 Aug 2014 06:45:54 +0000 From: =?iso-8859-1?Q?Beno=EEt?= Canet Message-ID: <20140826064554.GA13982@nodalink.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> <20140826044204.GB2517@T430.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20140826044204.GB2517@T430.nay.redhat.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: Fam Zheng Cc: kwolf@redhat.com, jcody@redhat.com, stefanha@redhat.com, =?iso-8859-1?Q?Beno=EEt?= Canet , qemu-devel@nongnu.org On Tue, Aug 26, 2014 at 12:42:04PM +0800, Fam Zheng wrote: > 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 grap= h right in the > > > > > > middle of BDS chains (block-mirror's replace parameter for ex= ample) QEMU needs > > > > > > to properly block and unblock whole BDS subtrees; recursion i= s 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 = properly, > > > > > because the op blocker may not work in the same way for all typ= es of BDS > > > > > connections. In other words, the choosing of op blockers are l= ikely > > > > > conditional on graph edge types, that's why backing_blocker was= added here. For > > > > > example, A VMDK extent connection will probably need a differen= t set of > > > > > blockers than bs->file connection. > > > > >=20 > > > > > So could you explain in which cases is the recursive blocking/u= nblocking > > > > > useful? > > > >=20 > > > > It's designed for the new crop of block operations operating on B= DS located in > > > > the middle of the backing chain: Jeff's patches, intermediate liv= e 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. The= se > > > operations are in the category of operations that update graph topo= logy, > > > 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? > >=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 = types other > > > than backing_hd, for example ->file, (vmdk)->extents or (quorum)->q= crs, 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 rec= ursive > > blocking will help to block any operation done directly on any of the= children. >=20 > At what points should block layer recursively block/unblock the operati= ons in > this quorum case? When the streaming starts it should block all the top bs children. So after when an operation tries to operate on a child of the top bs it w= ill be forbidden. The beauty of it is that recursive blockers can easily replace regular bl= ockers. >=20 > Fam >=20 > >=20 > > It's usefull since we introduced drive-mirror replace which will repl= ace an arbitrary > > node of a quorum at the end of the mirroring operation.