From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G7Rsj-00078J-3T for qemu-devel@nongnu.org; Mon, 31 Jul 2006 03:08:05 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G7Rse-00076b-OO for qemu-devel@nongnu.org; Mon, 31 Jul 2006 03:08:04 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G7Rse-00076Y-Jg for qemu-devel@nongnu.org; Mon, 31 Jul 2006 03:08:00 -0400 Received: from [195.184.98.160] (helo=virtualhost.dk) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1G7RvG-0004LN-D4 for qemu-devel@nongnu.org; Mon, 31 Jul 2006 03:10:42 -0400 Received: from [62.242.22.158] (helo=router.home.kernel.dk) by virtualhost.dk with esmtp (Exim 3.36 #1) id 1G7Rsd-00025Z-00 for qemu-devel@nongnu.org; Mon, 31 Jul 2006 09:07:59 +0200 Received: from nelson.home.kernel.dk ([192.168.0.33] helo=kernel.dk) by router.home.kernel.dk with esmtp (Exim 4.51) id 1G7Rsb-0000zr-7Y for qemu-devel@nongnu.org; Mon, 31 Jul 2006 09:07:57 +0200 Date: Mon, 31 Jul 2006 09:08:22 +0200 From: Jens Axboe Subject: Re: [Qemu-devel] Re: [RFC][PATCH] make sure disk writes actually hit disk Message-ID: <20060731070822.GD14748@suse.de> References: <44CA6B76.7000004@redhat.com> <44CA7102.1020402@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44CA7102.1020402@redhat.com> 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, Jul 28 2006, Rik van Riel wrote: > Anthony Liguori wrote: > > >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 > > Agreed, AIO is the way to go in the long run. > > >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. > > You're right. This O_SYNC bandaid should probably stay in place > to prevent data corruption, until the AIO framework is ready to > be used. O_SYNC is horrible, it'll totally kill performance. QEMU is basically just a write cache enabled disk and it supports disk flushes as well. So essentially it's the OS on top of QEMU that needs to take care for flushing data out, like using barriers on the file system and propagating fsync() properly down. -- Jens Axboe