From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G6Yhb-00043I-DT for qemu-devel@nongnu.org; Fri, 28 Jul 2006 16:12:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G6Yha-00042Q-6k for qemu-devel@nongnu.org; Fri, 28 Jul 2006 16:12:54 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G6Yha-00042K-3K for qemu-devel@nongnu.org; Fri, 28 Jul 2006 16:12:54 -0400 Received: from [80.91.229.2] (helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1G6Yjd-0008L5-Kg for qemu-devel@nongnu.org; Fri, 28 Jul 2006 16:15:01 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1G6YhB-0002dg-LZ for qemu-devel@nongnu.org; Fri, 28 Jul 2006 22:12:29 +0200 Received: from cpe-70-116-9-243.austin.res.rr.com ([70.116.9.243]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 28 Jul 2006 22:12:29 +0200 Received: from anthony by cpe-70-116-9-243.austin.res.rr.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 28 Jul 2006 22:12:29 +0200 From: Anthony Liguori Date: Fri, 28 Jul 2006 15:12:04 -0500 Message-ID: References: <44CA6B76.7000004@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit Sender: news Subject: [Qemu-devel] Re: [RFC][PATCH] make sure disk writes actually hit disk Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Fri, 28 Jul 2006 15:54:30 -0400, Rik van Riel wrote: > This is the simple approach to making sure that disk writes actually hit > disk before we tell the guest OS that IO has completed. Thanks to > DMA_MULTI_THREAD the performance still seems to be adequate. Hi Rik, Right now Fabrice is working on rewriting the block API to be asynchronous. There's been quite a lot of discussion about why using threads isn't a good idea for this (I wish Xen wouldn't use this patch but that's another conversation :-)). The async block API will allow the use of different kinds of async "backends". The default (on Linux) will be posix-aio. I'm currently working on an HTTP backend and will also write a linux-aio (which, of course, will be using O_DIRECT). > A fancier solution would be to make the sync/non-sync behaviour of the > qemu disk backing store tunable from the guest OS, by tuning the IDE disk > write cache on/off with hdparm, and having hw/ide.c call ->fsync functions > in the block backends. With a proper async API, is there any reason why we would want this to be tunable? I don't think there's much of a benefit of prematurely claiming a write is complete especially once the SCSI emulation can support multiple simultaneous requests. I was hoping to just make linux-aio the default if it was available... Regards, Anthony Liguori > I'm willing to code up the fancy solution if people prefer that.