From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:46607)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1T9YZw-0007Yz-98
	for qemu-devel@nongnu.org; Thu, 06 Sep 2012 05:40:56 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1T9YZs-0006cm-7Q
	for qemu-devel@nongnu.org; Thu, 06 Sep 2012 05:40:52 -0400
Received: from mx1.redhat.com ([209.132.183.28]:42026)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1T9YZr-0006cc-VM
	for qemu-devel@nongnu.org; Thu, 06 Sep 2012 05:40:48 -0400
Message-ID: <50486F24.2010106@redhat.com>
Date: Thu, 06 Sep 2012 11:38:44 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <20120809130010.GA7960@in.ibm.com>
	<20120809130216.GC7960@in.ibm.com>
	<20120905074106.GA28080@in.ibm.com>
	<20120905095431.GB28080@in.ibm.com>
	<50484F63.5050406@redhat.com> <504867A9.3050808@redhat.com>
In-Reply-To: <504867A9.3050808@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH v6 2/2] block: Support GlusterFS as a QEMU
	block backend
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>, Anand Avati <aavati@redhat.com>, Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>, Vijay Bellur <vbellur@redhat.com>, Amar Tumballi <amarts@redhat.com>, qemu-devel@nongnu.org, Blue Swirl <blauwirbel@gmail.com>, bharata@linux.vnet.ibm.com

Il 06/09/2012 11:06, Kevin Wolf ha scritto:
>> > If it works, I think this change would be preferrable to using a "magic"
>> > BH in every driver.
> The way it works in posix-aio-compat is that the request is first
> removed from the list and then the callback is called. This way
> posix_aio_flush() can return 0 and bdrv_drain_all() completes.

So the same could be done in gluster: first decrease qemu_aio_count,
then call the callback, then call qemu_aio_release.

But in either case, wouldn't that leak the AIOCBs until the end of
qcow2_create?

The AIOCB is already invalid at the time the callback is entered, so we
could release it before the call.  However, not all implementation of
AIO are ready for that and I'm not really in the mood for large scale
refactoring...

Paolo