From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50365) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wz3z7-0003iJ-Ip for qemu-devel@nongnu.org; Mon, 23 Jun 2014 09:08:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wz3yy-0002sz-I5 for qemu-devel@nongnu.org; Mon, 23 Jun 2014 09:08:33 -0400 Received: from mail-we0-x231.google.com ([2a00:1450:400c:c03::231]:61096) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wz3yy-0002rG-At for qemu-devel@nongnu.org; Mon, 23 Jun 2014 09:08:24 -0400 Received: by mail-we0-f177.google.com with SMTP id u56so7033071wes.36 for ; Mon, 23 Jun 2014 06:08:22 -0700 (PDT) Date: Mon, 23 Jun 2014 21:08:09 +0800 From: Stefan Hajnoczi Message-ID: <20140623130809.GB26269@stefanha-thinkpad.redhat.com> References: <20140619091716.GS21236@stefanha-thinkpad.redhat.com> <20140619162600.GB6096@localhost.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="St7VIuEGZ6dlpu13" Content-Disposition: inline In-Reply-To: <20140619162600.GB6096@localhost.localdomain> 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: Jeff Cody Cc: kwolf@redhat.com, benoit.canet@irqsave.net, pkrempa@redhat.com, famz@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com --St7VIuEGZ6dlpu13 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 in > all cases except where images files share a common BDS. 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). 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? Besides this issue, your approach seems like the quickest safe solution for 2.1. > 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. Right now I don't think we share BDS chains. Stefan --St7VIuEGZ6dlpu13 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTqCa5AAoJEJykq7OBq3PICBsIALBOyyFKiPFLt2h+KBgxP9x2 bw6V+dL/oG6/asv63SW8N0IsvyiFQPBROOuGz/8cKrJW5vK4NQap6dPpDR51YtcI /aKt4lJfCOvpgiPG2U/Skfq2HWWiHtaV22gFWCDGd6JQd4SIEC97VwIWrKg7GYLY PvAM7Lyn5wrMRHBgoDHMyIXyIMkzn9a7yygxS1Dq+L3vAN6Ze3mr5Z1C1I0VMTXY oYA2GkDDkHXFqjVZUkeFY4Z+We1XZHxDRbKxG4Y7BsSg9P07UHuSuE1EafpDprL3 CvI6RtzY3ymAl6tYXOa7253Cm+5TPzQICaq2iRTn65JuUF/E2hzewZtB7k4r1OE= =7DQJ -----END PGP SIGNATURE----- --St7VIuEGZ6dlpu13--