From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56982) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WxiuS-0002pp-PP for qemu-devel@nongnu.org; Thu, 19 Jun 2014 16:26:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WxiuN-00074L-Qm for qemu-devel@nongnu.org; Thu, 19 Jun 2014 16:26:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1087) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WxiuN-00074C-HT for qemu-devel@nongnu.org; Thu, 19 Jun 2014 16:26:07 -0400 Message-ID: <53A3475C.7000607@redhat.com> Date: Thu, 19 Jun 2014 14:26:04 -0600 From: Eric Blake MIME-Version: 1.0 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> In-Reply-To: <20140619202043.GA18306@irqsave.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="q34LoRgQvQ3wwl1cHNdAfROfcP2cqXTN4" Subject: Re: [Qemu-devel] [PATCH] block: Make op blocker recursive List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QmVub8OudCBDYW5ldA==?= Cc: kwolf@redhat.com, jcody@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --q34LoRgQvQ3wwl1cHNdAfROfcP2cqXTN4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06/19/2014 02:20 PM, Beno=C3=AEt Canet wrote: >> 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 patterns= >> rather than operations, we want the mere act of being a backing file t= o >> automatically put a guest_write block on base and snap1 (we must not >> modify the backing chain out of underneath active). But now suppose w= e >> do two operations in parallel - we take a fleecing export of active, a= nd >> 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 we >> unconditionally clear those additional restrictions on the first of th= e >> two jobs ending, that would inappropriately stop blocking that action >> from the still on-going second action. The only way I see around that= >> 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 d= etached > from the graph and will be destroyed. >=20 > It does happen in drive mirror and bdrv_unrefing it would lead to a fai= led > assertion. Okay, you may have a use case there. Or you may just be highlighting a bug. Consider what happens if we have: base <- snap1 <- active then open a fleecing NBD view of snap1: base <- snap1 <- active \-- fleecing then do a blockpull into active: active base <- snap1 <- fleecing 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. >=20 > So the reset function take care of removing blocker of dead subtrees. >=20 > What would be a cleaner solution ? I'm not honestly sure. Which is why we're thinking about design gotchas at the moment ;) --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --q34LoRgQvQ3wwl1cHNdAfROfcP2cqXTN4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTo0dcAAoJEKeha0olJ0NqeJoH/jQED+TZjcI7+sI4i+IhvoDR zF99sp0dcfb78oUiZB4JFomczjGeDAbPsbWFQu5E60jagEUDu+fqHokSbUjUfqPk wrgon6TZe3uP3wsrsmA/VaUhaaAuOE6BIS1IWIthQlhkVjNURmgfi12D9SHLZ0EE EbFjZKi0NZtgyt9dOLxzGcfTG+aPKKZbxnMmUohbGrpN1SEYXbH4J3tyIz8R9A8w qBibcrj1WE/XBUvoABg2c2Fl+LlglmwwpEQUEICUe0An0HC9EqJIXlvKBLHu4nEI ekur2YuvDlqatSA4tEsXCq+iGIFN5Wsg7O0UbHFa6j4rULL0zfkzIqZSrQNz09Q= =YQLw -----END PGP SIGNATURE----- --q34LoRgQvQ3wwl1cHNdAfROfcP2cqXTN4--