From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G7SyK-00046y-9y for qemu-devel@nongnu.org; Mon, 31 Jul 2006 04:17:56 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G7SyI-00045t-Ph for qemu-devel@nongnu.org; Mon, 31 Jul 2006 04:17:55 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G7SyI-00045l-Ka for qemu-devel@nongnu.org; Mon, 31 Jul 2006 04:17:54 -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 1G7T0v-0001TH-73 for qemu-devel@nongnu.org; Mon, 31 Jul 2006 04:20:37 -0400 Received: from [62.242.22.158] (helo=router.home.kernel.dk) by virtualhost.dk with esmtp (Exim 3.36 #1) id 1G7SyI-0008C9-00 for qemu-devel@nongnu.org; Mon, 31 Jul 2006 10:17:54 +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 1G7SyG-00024y-98 for qemu-devel@nongnu.org; Mon, 31 Jul 2006 10:17:52 +0200 Date: Mon, 31 Jul 2006 10:18:17 +0200 From: Jens Axboe Subject: Re: [Qemu-devel] [RFC][PATCH] make sure disk writes actually hit disk Message-ID: <20060731081817.GJ14748@suse.de> References: <44CA6B76.7000004@redhat.com> <44CB310B.9060308@bellard.org> <44CB77DF.9030700@redhat.com> <20060731070844.GF14748@suse.de> <5051934D-ED2D-4F2B-A456-F6195CC47393@elis.ugent.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5051934D-ED2D-4F2B-A456-F6195CC47393@elis.ugent.be> 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 Mon, Jul 31 2006, Jonas Maebe wrote: > > On 31 jul 2006, at 09:08, Jens Axboe wrote: > > >>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. > > The problem is that supposedly many OS'es are broken in this way. See > http://lists.apple.com/archives/darwin-dev/2005/Feb/msg00072.html Well, as others have written here as well, then their OS are broken on "real" hardware as well. I wouldn't be adverse to a QEMU work-around, but O_SYNC is clearly not a viable alternative! We could make QEMU behave more like a real hard drive when it has aio support, "flushing" dirty cache out in a manner more closely mimicking what a drive would do instead of relying on the page cache writeout deciding to write it out. -- Jens Axboe