From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=54072 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Pl3DU-0008N1-7G
	for qemu-devel@nongnu.org; Thu, 03 Feb 2011 12:43:59 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1Pl3Cm-0001eC-54
	for qemu-devel@nongnu.org; Thu, 03 Feb 2011 12:42:54 -0500
Received: from mx1.redhat.com ([209.132.183.28]:33199)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kwolf@redhat.com>) id 1Pl3Cl-0001e3-Rz
	for qemu-devel@nongnu.org; Thu, 03 Feb 2011 12:42:52 -0500
Message-ID: <4D4AE97C.60307@redhat.com>
Date: Thu, 03 Feb 2011 18:44:28 +0100
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
References: <OFE9BAD126.A83D3339-ON8525782C.005D13B8-8525782C.005F351D@us.ibm.com>
In-Reply-To: <OFE9BAD126.A83D3339-ON8525782C.005D13B8-8525782C.005F351D@us.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: QCOW2 bugs releated to qcow2_aio_cancel()
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.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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Chunqiang Tang <ctang@us.ibm.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>, qemu-devel@nongnu.org

Am 03.02.2011 18:21, schrieb Chunqiang Tang:
> Hi Kevin,
> 
> Fast Virtual Disk (FVD) has an automated testing tool (see 
> http://wiki.qemu.org/Features/FVD/Engineering). For a long time, I knew 
> that QCOW2 could not pass the automated tests. Today I finally sit down to 
> look into those bugs. I already submitted multiple patches for different 
> bugs, but there is one case that I am not certain how to handle. Instead 
> of creating a potentially broken patch, I though you might be able to 
> handle it better than me. Bugs showed up when the testing tool injected 
> aio cancel.

We have discussed this before and yes, aio_cancel is a problem. It is
very hard to do this correctly, and so most block drivers just wait for
completion instead of actually cancelling anything.

Given that a cancel shouldn't happen too often, I think it would be
reasonable to take the same approach for qcow2. I don't think adding a
lot of complexity for getting this right is justified.

Stefan, what do you think? Maybe we could even have a default
implementation in generic block code?

Kevin