From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G6sgT-0007zK-AX for qemu-devel@nongnu.org; Sat, 29 Jul 2006 13:33:05 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G6sgR-0007wT-KU for qemu-devel@nongnu.org; Sat, 29 Jul 2006 13:33:05 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G6sgR-0007wQ-Ff for qemu-devel@nongnu.org; Sat, 29 Jul 2006 13:33:03 -0400 Received: from [64.233.182.186] (helo=nf-out-0910.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G6sih-0005X3-E3 for qemu-devel@nongnu.org; Sat, 29 Jul 2006 13:35:23 -0400 Received: by nf-out-0910.google.com with SMTP id a25so102368nfc for ; Sat, 29 Jul 2006 10:33:02 -0700 (PDT) Message-ID: <23bcb8700607291033q7ce66872j2ce2d830a8578dbc@mail.gmail.com> Date: Sat, 29 Jul 2006 13:33:01 -0400 From: "Bill C. Riemers" Sender: docbill@gmail.com Subject: Re: [Qemu-devel] [RFC][PATCH] make sure disk writes actually hit disk In-Reply-To: <44CB77DF.9030700@redhat.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_30481_3487789.1154194381976" References: <44CA6B76.7000004@redhat.com> <44CB310B.9060308@bellard.org> <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 ------=_Part_30481_3487789.1154194381976 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline How about compromising, and making the patch a run time option. Presumably this is only a problem when the virtual machine is not properly shutdown. For those ho want the extra security of knowing the data will be written regardless of the shutdown status they can enable the flag. By default it could be turned off. Then everybody can be happy. Bill On 7/29/06, Rik van Riel wrote: > > 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 > > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > ------=_Part_30481_3487789.1154194381976 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline How about compromising, and making the patch a run time option.  Presumably this is only a problem when the virtual machine is not properly shutdown.  For those ho want the extra security of knowing the data will be written regardless of the shutdown status they can enable the flag.  By default it could be turned off.  Then everybody can be happy.

Bill


On 7/29/06, Rik van Riel <riel@redhat.com> wrote:
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


_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

------=_Part_30481_3487789.1154194381976--