From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54334) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axaJL-0008P8-CS for qemu-devel@nongnu.org; Tue, 03 May 2016 09:24:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1axaJ9-0002BJ-Kv for qemu-devel@nongnu.org; Tue, 03 May 2016 09:24:17 -0400 Date: Tue, 3 May 2016 15:23:24 +0200 From: Kevin Wolf Message-ID: <20160503132324.GE3917@noname.str.redhat.com> References: <5720BFDB.60600@redhat.com> <20160429151826.GM4350@noname.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v9 07/11] block: Add QMP support for streaming to an intermediate layer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alberto Garcia Cc: Max Reitz , qemu-devel@nongnu.org, qemu-block@nongnu.org, Eric Blake , Stefan Hajnoczi Am 03.05.2016 um 14:50 hat Alberto Garcia geschrieben: > On Fri 29 Apr 2016 05:18:26 PM CEST, Kevin Wolf wrote: > > This patch errors out if we can't find the active layer. Sounds safe > > and appropriate for an initial version. The real solution isn't to > > improve the magic to find the root node, but to remove the need to > > find it (by getting the new op blockers). > > Well, I agree with the fact that what we really want is not to block the > active layer at all, but I don't see how any new op blockers are going > to solve that. > > The situation is that we can't allow two block jobs in the same chain at > the moment, and I only see three solutions: > > a) each job blocks the whole chain (what this series does). > > b) each job checks that no other job is running on the same chain. > Maybe cleaner? But it would require modifying all other jobs. > > c) we fix bdrv_reopen() so we can actually run both jobs at the same > time. I'm wondering if pausing all block jobs between > bdrv_reopen_prepare() and bdrv_reopen_commit() would do the > trick. Opinions? I would have to read up the details of the problem again, but I think with bdrv_drained_begin/end() we actually have the right tool now to fix it properly. We may need to pull up the drain (bdrv_drain_all() today) from bdrv_reopen_multiple() to its caller and just assert it in the function itself, but there shouldn't be much more to it than that. Kevin