From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Kp59O-0005OC-O0
	for qemu-devel@nongnu.org; Sun, 12 Oct 2008 13:54:42 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Kp59N-0005MQ-0z
	for qemu-devel@nongnu.org; Sun, 12 Oct 2008 13:54:42 -0400
Received: from [199.232.76.173] (port=53877 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Kp59M-0005MI-Mu
	for qemu-devel@nongnu.org; Sun, 12 Oct 2008 13:54:40 -0400
Received: from wr-out-0506.google.com ([64.233.184.234]:62457)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <anthony@codemonkey.ws>) id 1Kp59M-0004IR-A3
	for qemu-devel@nongnu.org; Sun, 12 Oct 2008 13:54:40 -0400
Received: by wr-out-0506.google.com with SMTP id c46so875631wra.18
	for <qemu-devel@nongnu.org>; Sun, 12 Oct 2008 10:54:39 -0700 (PDT)
Message-ID: <48F239DB.6050302@codemonkey.ws>
Date: Sun, 12 Oct 2008 12:54:35 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
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>
In-Reply-To: <48F14814.7000805@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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: Chris Wright <chrisw@redhat.com>, Mark McLoughlin <markmc@redhat.com>, Ryan Harper <ryanh@us.ibm.com>, Laurent Vivier <Laurent.Vivier@bull.net>, kvm-devel <kvm-devel@lists.sourceforge.net>

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.

The fact that the virtualization layer has a cache is really not that 
unusual.

Regards,

Anthony Liguori