From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G7J2n-0004WL-PV for qemu-devel@nongnu.org; Sun, 30 Jul 2006 17:41:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G7J2k-0004TR-R8 for qemu-devel@nongnu.org; Sun, 30 Jul 2006 17:41:53 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G7J2k-0004TM-OO for qemu-devel@nongnu.org; Sun, 30 Jul 2006 17:41:50 -0400 Received: from [81.29.64.88] (helo=mail.shareable.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1G7J5G-0000jS-V8 for qemu-devel@nongnu.org; Sun, 30 Jul 2006 17:44:27 -0400 Received: from mail.shareable.org (localhost [127.0.0.1]) by mail.shareable.org (8.12.11.20060308/8.12.11) with ESMTP id k6ULflPw006924 for ; Sun, 30 Jul 2006 22:41:47 +0100 Received: (from jamie@localhost) by mail.shareable.org (8.12.11.20060308/8.12.8/Submit) id k6ULflob006922 for qemu-devel@nongnu.org; Sun, 30 Jul 2006 22:41:47 +0100 Date: Sun, 30 Jul 2006 22:41:47 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [RFC][PATCH] make sure disk writes actually hit disk Message-ID: <20060730214147.GA6255@mail.shareable.org> 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 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. I've seen this with Linux 2.4 kernels writing to ext3 (real, not virtual). Filesystem metadata gets corrupted from time to time if power is removed, because write ordering is not preserved. Disabling IDE write caching fixes it, but the performance impact is huge on some systems. Linux 2.6 kernels will issue IDE cache flush commands, at least with ext3, to commit data to disk when fsync is called, and to preserve journal/metadata ordering. Doesn't qemu fsync the host file corresponding to the emulated disk, when the guest OS issues an IDE cache flush? For IDE emulation to be as reliable for data storage as a real disk, it should: - fsync the host file whenever the guest OS issues an IDE cache flush command. - use O_SYNC (or fsync after each write or aio equivalent, etc.) _only_ when the guest OS disables the IDE disk cache (not done by default). -- JAmie