From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G6qI7-0002r8-1G for qemu-devel@nongnu.org; Sat, 29 Jul 2006 10:59:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G6qI5-0002qa-5R for qemu-devel@nongnu.org; Sat, 29 Jul 2006 10:59:46 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G6qI5-0002qV-2d for qemu-devel@nongnu.org; Sat, 29 Jul 2006 10:59:45 -0400 Received: from [66.187.233.31] (helo=mx1.redhat.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G6qKJ-0000uv-DD for qemu-devel@nongnu.org; Sat, 29 Jul 2006 11:02:03 -0400 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k6TExi5p032309 for ; Sat, 29 Jul 2006 10:59:44 -0400 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.76.12]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k6TExiqn000404 for ; Sat, 29 Jul 2006 10:59:44 -0400 Received: from [10.0.13.9] (vpn-248-25.boston.redhat.com [10.13.248.25]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id k6TExhAB017237 for ; Sat, 29 Jul 2006 10:59:43 -0400 Message-ID: <44CB77DF.9030700@redhat.com> Date: Sat, 29 Jul 2006 10:59:43 -0400 From: Rik van Riel MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC][PATCH] make sure disk writes actually hit disk References: <44CA6B76.7000004@redhat.com> <44CB310B.9060308@bellard.org> In-Reply-To: <44CB310B.9060308@bellard.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 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... 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. -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan