From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41477) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wz53a-0007b6-Sr for qemu-devel@nongnu.org; Mon, 23 Jun 2014 10:17:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wz53S-0006TX-Tz for qemu-devel@nongnu.org; Mon, 23 Jun 2014 10:17:14 -0400 Received: from lputeaux-656-01-25-125.w80-12.abo.wanadoo.fr ([80.12.84.125]:51931 helo=paradis.irqsave.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wz53S-0006TM-OB for qemu-devel@nongnu.org; Mon, 23 Jun 2014 10:17:06 -0400 Date: Mon, 23 Jun 2014 16:17:05 +0200 From: =?iso-8859-1?Q?Beno=EEt?= Canet Message-ID: <20140623141705.GA26906@irqsave.net> References: <20140619091716.GS21236@stefanha-thinkpad.redhat.com> <20140619162600.GB6096@localhost.localdomain> <20140623130809.GB26269@stefanha-thinkpad.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20140623130809.GB26269@stefanha-thinkpad.redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v6 for 2.1 00/10] Modify block jobs to use node-names List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: kwolf@redhat.com, benoit.canet@irqsave.net, pkrempa@redhat.com, famz@redhat.com, Jeff Cody , qemu-devel@nongnu.org, stefanha@redhat.com The Monday 23 Jun 2014 =E0 21:08:09 (+0800), Stefan Hajnoczi wrote : > On Thu, Jun 19, 2014 at 12:26:00PM -0400, Jeff Cody wrote: > > On Thu, Jun 19, 2014 at 05:17:16PM +0800, Stefan Hajnoczi wrote: > > > On Tue, Jun 17, 2014 at 05:53:48PM -0400, Jeff Cody wrote: > > > Let's discuss this topic in a sub-thread and figure out what to do = for > > > QEMU 2.1. This is an important issue to solve before the release > > > because we can't change QMP command semantics easily later. > > >=20 > > > My questions are: > > > a. How do we fix resize, snapshot-sync, etc? It seems like we need= to > > > propagate child op blockers. > > >=20 > > > b. Is it a good idea to perform op blocker checks on the root node? > > > It's inconsistent with resize, snapshot-sync, etc. Permissions = in > > > BDS graphs with multiple root nodes (e.g. guest device and NBD > > > run-time server) will be different depending on which root you > > > specify. > >=20 > > I don't think (b) is the ultimate solution. It is used as a stop-gap > > because op blockers in the current implementation is essentially > > analogous to the in-use flag. But is it good enough for 2.1? If > > *everything* checks the topmost node in 2.1, then I think we are OK i= n > > all cases except where images files share a common BDS. >=20 > Checking op blockers on the root node as a stop-gap is a good idea. > Let's apply it across all commands (e.g. snapshot-sync, resize). >=20 > Fam pointed out that this approach is vulnerable to blockdev-add, where > blockers could be set/checked on an incomplete BDS graph (since you can > add new nodes on top). Do we need to move the blockers up the graph if > a new root node is inserted? >=20 > Besides this issue, your approach seems like the quickest safe solution > for 2.1. I agree that always blocking the top BDS would be tactical. Even it would need to move the blocker on the root on node insertion it w= ould solve the issues I have in the quorum maintainances patches of recursive = BDS loops and ownerships. Best regards Beno=EEt >=20 > > The ability for internal BDSs to share a common base BDS makes some > > block jobs unsafe currently, I believe. A crude and ugly fix is to > > only allow a single block-job to occur at any given time, but that > > doesn't seem feasible, so let's ignore that. >=20 > Right now I don't think we share BDS chains. >=20 > Stefan