From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KpDvk-00084c-Hl for qemu-devel@nongnu.org; Sun, 12 Oct 2008 23:17:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KpDvh-00084B-4Z for qemu-devel@nongnu.org; Sun, 12 Oct 2008 23:17:11 -0400 Received: from [199.232.76.173] (port=35279 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KpDvg-000842-UH for qemu-devel@nongnu.org; Sun, 12 Oct 2008 23:17:08 -0400 Received: from ag-out-0708.google.com ([72.14.246.242]:64122) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KpDvf-0005Hw-LN for qemu-devel@nongnu.org; Sun, 12 Oct 2008 23:17:08 -0400 Received: by ag-out-0708.google.com with SMTP id 31so1745602agc.5 for ; Sun, 12 Oct 2008 20:17:01 -0700 (PDT) Message-ID: <48F2BDA9.3060008@codemonkey.ws> Date: Sun, 12 Oct 2008 22:16:57 -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> <48F2A294.4020303@codemonkey.ws> <48F2ADD9.9000804@redhat.com> In-Reply-To: <48F2ADD9.9000804@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: > So, if your proposed default value for the cache is in effect, then > O_DSYNC > should provide the write-thru required by the guests use of O_DIRECT > on the > writes. However, if the default cache value is not used and its set to > cache=on, and if the guest is using O_DIRECT or O_DSYNC, I feel there are The option would be cache=writeback and the man pages have a pretty clear warning in it that it could lead to data loss. It's used for -snapshot and it's totally safe for that (and improves write performance for that case). It's also there because a number of people expressed a concern that they did not care about data integrity and wished to be able to get the performance boost. I don't see a harm in that since I think we'll now have adequate documentation. Regards, Anthony Liguori > > issues that need to be addressed. > > -mark > >>> 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 >>>> >>>> >>> >>> >>> >> >> >> > > >