From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G7US8-0006if-J3 for qemu-devel@nongnu.org; Mon, 31 Jul 2006 05:52:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G7US7-0006gd-Aq for qemu-devel@nongnu.org; Mon, 31 Jul 2006 05:52:48 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G7US7-0006gN-72 for qemu-devel@nongnu.org; Mon, 31 Jul 2006 05:52:47 -0400 Received: from [64.233.182.188] (helo=nf-out-0910.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G7UUk-0001aS-Cl for qemu-devel@nongnu.org; Mon, 31 Jul 2006 05:55:30 -0400 Received: by nf-out-0910.google.com with SMTP id a25so394231nfc for ; Mon, 31 Jul 2006 02:52:45 -0700 (PDT) Message-ID: Date: Mon, 31 Jul 2006 11:52:45 +0200 From: "andrzej zaborowski" Sender: balrogg@gmail.com Subject: Re: [Qemu-devel] [RFC][PATCH] make sure disk writes actually hit disk In-Reply-To: <20060730214147.GA6255@mail.shareable.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44CA6B76.7000004@redhat.com> <44CB310B.9060308@bellard.org> <44CB77DF.9030700@redhat.com> <20060730214147.GA6255@mail.shareable.org> Reply-To: balrogg@gmail.com, 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 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. 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. > > 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 > > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > -- balrog 2oo6 Dear Outlook users: Please remove me from your address books http://www.newsforge.com/article.pl?sid=03/08/21/143258