From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40207) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XS2SG-0007UR-4D for qemu-devel@nongnu.org; Thu, 11 Sep 2014 07:22:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XS2S7-0005uN-FC for qemu-devel@nongnu.org; Thu, 11 Sep 2014 07:22:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:3939) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XS2S7-0005uE-8b for qemu-devel@nongnu.org; Thu, 11 Sep 2014 07:22:15 -0400 Date: Thu, 11 Sep 2014 13:22:05 +0200 From: Kevin Wolf Message-ID: <20140911112205.GD3891@noname.redhat.com> References: <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> <20140826064554.GA13982@nodalink.com> <20140904204256.GF25226@stefanha-thinkpad.redhat.com> <20140910085419.GB26233@fam-t430.nay.redhat.com> <54106ADB.7060205@redhat.com> <20140910154938.GC30703@nodalink.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20140910154938.GC30703@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: Fam Zheng , Stefan Hajnoczi , jcody@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com Am 10.09.2014 um 17:49 hat Beno=EEt Canet geschrieben: > On Wed, Sep 10, 2014 at 09:14:35AM -0600, Eric Blake wrote: > > On 09/10/2014 02:54 AM, Fam Zheng wrote: > >=20 > > >> 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-commi= t jobs > > >> on the same partial chain (that's a bad thing because it can lead = to > > >> corruption). > > >=20 > > > 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. > >=20 > > IIRC, Jeff Cody proposed patches for qemu 2.1 that would have done th= is, > > but we dropped them for that release in order to get the recursive > > blockers sorted out first. > >=20 > > > > > > 2) Regardless of the answer to 1), I think we could use a similar a= pproach 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. > >=20 > > In that earlier thread, Jeff had some ideas that it is not so much th= e > > 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) >=20 > Does it mean I should pause this current series and task switch to anot= her > infrastucture task ? > I could switch to the block I/O accouting work. >=20 > What does the other developpers and maintainers think about it ? No, I think we should get this series, with comments addressed, merged. It's not a solution for all eternity because it tends to be more restrictive than necessary, but that's okay for now and it makes things safer. We'll have to discuss more about blockers at KVM Forum, but that's the second part: Lifting unnecessary restrictions. This is tricky and won't be done for 2.2, so in the meantime we want this patch (and I expect we can reuse some parts of it even with Jeff's approach, so it won't be wasted work). We just shouldn't try to sink much time here because we know that it's only preliminary. Let's just get something that works good enough for now, it doesn't have to be perfect. Splitting into SOURCE/TARGET and similar things to make it less restrictive are probably not worth it. Kevin