From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Mvu1E-0000ME-Oy
	for qemu-devel@nongnu.org; Thu, 08 Oct 2009 10:31:00 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Mvu19-0000JS-Kd
	for qemu-devel@nongnu.org; Thu, 08 Oct 2009 10:30:59 -0400
Received: from [199.232.76.173] (port=35347 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Mvu19-0000JH-2y
	for qemu-devel@nongnu.org; Thu, 08 Oct 2009 10:30:55 -0400
Received: from mail-fx0-f214.google.com ([209.85.220.214]:44019)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1Mvu18-0000KF-Km
	for qemu-devel@nongnu.org; Thu, 08 Oct 2009 10:30:54 -0400
Received: by fxm10 with SMTP id 10so5606437fxm.8
	for <qemu-devel@nongnu.org>; Thu, 08 Oct 2009 07:30:53 -0700 (PDT)
Message-ID: <4ACDF797.4010805@codemonkey.ws>
Date: Thu, 08 Oct 2009 09:30:47 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH] qcow2: Bring synchronous read/write back
	to life
References: <1255006928-7600-1-git-send-email-kwolf@redhat.com>
In-Reply-To: <1255006928-7600-1-git-send-email-kwolf@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel@nongnu.org

Kevin Wolf wrote:
> When the synchronous read and write functions were dropped, they were replaced
> by generic emulation functions. Unfortunately, these emulation functions don't
> provide the same semantics as the original functions did.
>
> The original bdrv_read would mean that we read some data synchronously and that
> we won't be interrupted during this read. The latter assumption is no longer
> true with the emulation function which needs to use qemu_aio_poll and therefore
> allows the callback of any other concurrent AIO request to be run during the
> read.

Perhaps you could create a mechanism to freeze the qcow2 image by 
queuing all completions within qcow2 until the image was unfrozen.  This 
would have the same effect switching to synchronous read/write.

You may also have to queue new read/write requests...

Introducing sync read/write seems like a major step backwards to me.

Regards,

Anthony Liguori