From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G7UpQ-0007GH-MB for qemu-devel@nongnu.org; Mon, 31 Jul 2006 06:16:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G7UpM-00079a-3p for qemu-devel@nongnu.org; Mon, 31 Jul 2006 06:16:52 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G7UpM-00079X-09 for qemu-devel@nongnu.org; Mon, 31 Jul 2006 06:16:48 -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 1G7Urz-0003gP-N7 for qemu-devel@nongnu.org; Mon, 31 Jul 2006 06:19:31 -0400 Date: Mon, 31 Jul 2006 12:17:10 +0200 From: Jens Axboe Subject: Re: [Qemu-devel] [RFC][PATCH] make sure disk writes actually hit disk Message-ID: <20060731101710.GQ14748@suse.de> References: <44CA6B76.7000004@redhat.com> <44CB310B.9060308@bellard.org> <44CB77DF.9030700@redhat.com> <20060730214147.GA6255@mail.shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: balrogg@gmail.com, qemu-devel@nongnu.org On Mon, Jul 31 2006, andrzej zaborowski wrote: > On 30/07/06, Jamie Lokier wrote: > >Rik van Riel wrote: > >> This may look like hair splitting, but so far I've lost a > >> (test) postgresql database to this 3 times already. Not getting > >> the guest application's data to disk when the application calls > >> fsync is a recipe for disaster. > > > >Exactly the same thing happens with real IDE disks if IDE write > >caching (on the drive itself) is enabled, which it is by default. It > >is rarer, but it happens. > > The little difference with QEMU is that there are two caches above it: > the host OS'es software cache and the IDE hardware cache. When a guest > OS flushes its own software cache its precious data goes to the host's > software cache while the guest thinks it's already the IDE cache. This > is ofcourse of less importance because data in both caches (hard- and > software) is lost when the power is cut off. But the drive cache does not let the dirty data linger for as long as wht OS page/buffer cache. > IMHO what really makes IO unreliable in QEMU is that IO errors on the > host are not reported to the guest by the IDE emulation and there's an > exact place in hw/ide.c where they are arrogantly ignored. Send a patch, I'm pretty sure nobody would disagree :-) -- Jens Axboe