From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KpBIL-0000ua-WC for qemu-devel@nongnu.org; Sun, 12 Oct 2008 20:28:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KpBIK-0000ts-LR for qemu-devel@nongnu.org; Sun, 12 Oct 2008 20:28:20 -0400 Received: from [199.232.76.173] (port=60637 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KpBIK-0000tk-Am for qemu-devel@nongnu.org; Sun, 12 Oct 2008 20:28:20 -0400 Received: from mx1.redhat.com ([66.187.233.31]:55323) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KpBIK-00014j-Ft for qemu-devel@nongnu.org; Sun, 12 Oct 2008 20:28:20 -0400 Message-ID: <48F295F0.3020105@redhat.com> Date: Sun, 12 Oct 2008 20:27:28 -0400 From: Mark Wagner 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> In-Reply-To: <48F239DB.6050302@codemonkey.ws> 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 , kvm-devel , Laurent Vivier Anthony Liguori wrote: > Mark Wagner wrote: >> >> I do not believe that this means that the data is still sitting in the >> host cache. I realize it may not yet be on a disk, but, at a minimum, >> I would expect that is has been sent to the storage controller. Do you >> consider the hosts cache to be part of the storage subsystem ? > > Yes. And the storage subsystem is often complicated like this. > Consider if you had a hardware iSCSI initiator. The host just sees a > SCSI disk and when the writes are issued as completed, that simply means > the writes have gone to the iSCSI server. The iSCSI server may have its > own cache or some deep storage multi-level cached storage subsystem. > 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. 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. -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 > >