From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KpC7o-0002h8-AG for qemu-devel@nongnu.org; Sun, 12 Oct 2008 21:21:32 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KpC7m-0002go-LV for qemu-devel@nongnu.org; Sun, 12 Oct 2008 21:21:32 -0400 Received: from [199.232.76.173] (port=55862 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KpC7m-0002gl-J5 for qemu-devel@nongnu.org; Sun, 12 Oct 2008 21:21:30 -0400 Received: from mail-gx0-f19.google.com ([209.85.217.19]:62603) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KpC7m-0000qo-U7 for qemu-devel@nongnu.org; Sun, 12 Oct 2008 21:21:31 -0400 Received: by gxk12 with SMTP id 12so2922284gxk.10 for ; Sun, 12 Oct 2008 18:21:28 -0700 (PDT) Message-ID: <48F2A294.4020303@codemonkey.ws> Date: Sun, 12 Oct 2008 20:21:24 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] Disk integrity in QEMU References: <48EE38B9.2050106@codemonkey.ws> <48EF1D55.7060307@redhat.com> <48F0E83E.2000907@redhat.com> <48F10DFD.40505@codemonkey.ws> <48F14814.7000805@redhat.com> <48F239DB.6050302@codemonkey.ws> <48F295F0.3020105@redhat.com> In-Reply-To: <48F295F0.3020105@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; 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 Cc: Chris Wright , Mark McLoughlin , Ryan Harper , Laurent Vivier , kvm-devel Mark Wagner wrote: > If you stopped and listened to yourself, you'd see that you are making > my point... > > AFAIK, QEMU is neither designed nor intended to be an Enterprise > Storage Array, > I thought this group is designing a virtualization layer. However, > the persistent > argument is that since Enterprise Storage products will often > acknowledge a write > before the data is actually on the disk, its OK for QEMU to do the same. I think you're a little lost in this thread. We're going to have QEMU only acknowledge writes when they complete. I've already sent out a patch. Just waiting a couple days to let everyone give their input. > If QEMU > had a similar design to Enterprise Storage with redundancy, battery > backup, etc, I'd > be fine with it, but you don't. QEMU is a layer that I've also thought > was suppose > to be small, lightweight and unobtrusive that is silently putting > everyones data > at risk. > > The low-end iSCSI server from EqualLogic claims: > "it combines intelligence and automation with fault tolerance" > "Dual, redundant controllers with a total of 4 GB battery-backed > memory" > > AFAIK QEMU provides neither of these characteristics. So if this is your only concern, we're in violent agreement. You were previously arguing that we should use O_DIRECT in the host if we're not "lying" about write completions anymore. That's what I'm opposing because the details of whether we use O_DIRECT or not have absolutely nothing to do with data integrity as long as we're using O_DSYNC. Regards, Anthony Liguori > > -mark > >> The fact that the virtualization layer has a cache is really not that >> unusual. > Do other virtualization layers lie to the guest and indicate that the > data > has successfully been ACK'd by the storage subsystem when the data is > actually > still in the host cache? > > > -mark >> >> Regards, >> >> Anthony Liguori >> >> > > >