From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59880) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wxj4O-0007lQ-GB for qemu-devel@nongnu.org; Thu, 19 Jun 2014 16:36:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wxj4J-00029g-Ht for qemu-devel@nongnu.org; Thu, 19 Jun 2014 16:36:28 -0400 Received: from lputeaux-656-01-25-125.w80-12.abo.wanadoo.fr ([80.12.84.125]:51672 helo=paradis.irqsave.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wxj4J-00029S-BV for qemu-devel@nongnu.org; Thu, 19 Jun 2014 16:36:23 -0400 Date: Thu, 19 Jun 2014 22:36:21 +0200 From: =?iso-8859-1?Q?Beno=EEt?= Canet Message-ID: <20140619203620.GC18306@irqsave.net> References: <1403208081-18247-1-git-send-email-benoit.canet@irqsave.net> <1403208081-18247-2-git-send-email-benoit.canet@irqsave.net> <53A34460.8010302@redhat.com> <20140619202043.GA18306@irqsave.net> <53A3475C.7000607@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <53A3475C.7000607@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] block: Make op blocker recursive List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: =?iso-8859-1?Q?Beno=EEt?= Canet , kwolf@redhat.com, jcody@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com The Thursday 19 Jun 2014 =E0 14:26:04 (-0600), Eric Blake wrote : > On 06/19/2014 02:20 PM, Beno=EEt Canet wrote: >=20 > >> This unconditionally removes all blockers of type op of the subtree > >> > >> Yikes - is that really what we want? Or do we need to start doing > >> blocker reference counting? > >> > >> Consider: > >> > >> base <- snap1 <- active > >> > >> Looking at Jeff's proposal of making blockers based on access patter= ns > >> rather than operations, we want the mere act of being a backing file= to > >> automatically put a guest_write block on base and snap1 (we must not > >> modify the backing chain out of underneath active). But now suppose= we > >> do two operations in parallel - we take a fleecing export of active,= and > >> we start a drive-mirror on active. > >> > >> base <- snap1 <- active > >> | \-- fleecing > >> \-- copy > >> > >> Both of those actions should be doable in parallel, and both of them > >> probably put additional blocker restrictions on the chain. But if w= e > >> unconditionally clear those additional restrictions on the first of = the > >> two jobs ending, that would inappropriately stop blocking that actio= n > >> from the still on-going second action. The only way I see around th= at > >> is via reference-counted blocking. Definitely not 2.1 material (but > >> good to be thinking about it now, so we can get it in early in the 2= .2 > >> cycle). > >=20 > > I added this reset function for the case where a whole BDS subtree is= detached > > from the graph and will be destroyed. > >=20 > > It does happen in drive mirror and bdrv_unrefing it would lead to a f= ailed > > assertion. >=20 > Okay, you may have a use case there. Or you may just be highlighting a > bug. Consider what happens if we have: >=20 > base <- snap1 <- active >=20 > then open a fleecing NBD view of snap1: >=20 > base <- snap1 <- active > \-- fleecing >=20 > then do a blockpull into active: >=20 > active > base <- snap1 <- fleecing >=20 > that is, as long as the fleecing operation is live, we STILL need to > block base and snap1 from modification; even though active is no longer > dependent on them. Dropping the backing chain of active decreases the > reference count, but does not delete the BDS for base or snap1 because > those BDS are still in use by the fleecing operation. Blockers are already refcount like as they are implemented as linked list= grouped by operation types. As long an error message is still in a list the BDS is blocker. Best regards Beno=EEt >=20 > >=20 > > So the reset function take care of removing blocker of dead subtrees. > >=20 > > What would be a cleaner solution ? >=20 > I'm not honestly sure. Which is why we're thinking about design gotcha= s > at the moment ;) >=20 > --=20 > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org >=20