From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MvuUe-0002up-BL for qemu-devel@nongnu.org; Thu, 08 Oct 2009 11:01:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MvuUY-0002mj-Rx for qemu-devel@nongnu.org; Thu, 08 Oct 2009 11:01:23 -0400 Received: from [199.232.76.173] (port=43494 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MvuUX-0002m3-LY for qemu-devel@nongnu.org; Thu, 08 Oct 2009 11:01:17 -0400 Received: from mail-qy0-f199.google.com ([209.85.221.199]:61800) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MvuUW-0007Bi-9M for qemu-devel@nongnu.org; Thu, 08 Oct 2009 11:01:16 -0400 Received: by qyk37 with SMTP id 37so149773qyk.18 for ; Thu, 08 Oct 2009 08:01:15 -0700 (PDT) Message-ID: <4ACDFEB9.6090403@codemonkey.ws> Date: Thu, 08 Oct 2009 10:01:13 -0500 From: Anthony Liguori 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> <4ACDF797.4010805@codemonkey.ws> <4ACDFB64.1040106@redhat.com> In-Reply-To: <4ACDFB64.1040106@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org Kevin Wolf wrote: > Am 08.10.2009 16:30, schrieb Anthony Liguori: > >> 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. >> > > Right, I was expecting your reaction. ;-) I do even agree that it's not > nice to have the synchronous functions back. But removing them caused a > regression, so the removal should be reverted until it is done right. > > I just want to make clear that we're talking about data corruption here. > This is not just something that we can care about when we are bored some > time in the future. > Yeah, okay. Can we do a more direct revert though so that it's clearer in the commit log? > By the way, I don't think queuing things in qcow2 is the right thing to > do. It probably wouldn't even help if, say, VMDK implemented AIO and I > used a VMDK image as a backing file for qcow2. The real solution is to > fix the generic bdrv_read/write emulation. Now we just need to find the > best way to do this. > Ideally, you could say qemu_aio_wait(aiocb) and it would only wait for that particular request. I'm not convinced though that there aren't dependency issues though since we can generate synthetic aiocbs. Regards, Anthony Liguori