From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G7Rt1-0007JN-UQ for qemu-devel@nongnu.org; Mon, 31 Jul 2006 03:08:23 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G7Rt0-0007Hl-7x for qemu-devel@nongnu.org; Mon, 31 Jul 2006 03:08:23 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G7Rt0-0007HX-3o for qemu-devel@nongnu.org; Mon, 31 Jul 2006 03:08:22 -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 1G7Rvb-0004MT-Ph for qemu-devel@nongnu.org; Mon, 31 Jul 2006 03:11:04 -0400 Received: from [62.242.22.158] (helo=router.home.kernel.dk) by virtualhost.dk with esmtp (Exim 3.36 #1) id 1G7Rsz-00026o-00 for qemu-devel@nongnu.org; Mon, 31 Jul 2006 09:08:21 +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 1G7Rsx-00010m-KX for qemu-devel@nongnu.org; Mon, 31 Jul 2006 09:08:19 +0200 Date: Mon, 31 Jul 2006 09:08:44 +0200 From: Jens Axboe Subject: Re: [Qemu-devel] [RFC][PATCH] make sure disk writes actually hit disk Message-ID: <20060731070844.GF14748@suse.de> References: <44CA6B76.7000004@redhat.com> <44CB310B.9060308@bellard.org> <44CB77DF.9030700@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44CB77DF.9030700@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 Sat, Jul 29 2006, Rik van Riel wrote: > Fabrice Bellard wrote: > >Hi, > > > >Using O_SYNC for disk image access is not acceptable: QEMU relies on the > >host OS to ensure that the data is written correctly. > > This means that write ordering is not preserved, and on a power > failure any data written by qemu (or Xen fully virt) guests may > not be preserved. > > Applications running on the host can count on fsync doing the > right thing, meaning that if they call fsync, the data *will* > have made it to disk. Applications running inside a guest have > no guarantees that their data is actually going to make it > anywhere when fsync returns... Then the guest OS is broken. Applications issuing an fsync() should issue a flush (or write-through), the guest OS should propagate this knowledge through it's io stack and the QEMU hard drive should get notified. If the guest OS isn't doing what it's supposed to, QEMU can't help you. And, in fact, running your app on the same host OS with write back caching would screw you as well. The timing window will probably be larger with QEMU, but the problem is essentially the same. -- Jens Axboe