From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KrUDe-0007VJ-IZ
	for qemu-devel@nongnu.org; Sun, 19 Oct 2008 05:05:02 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KrUDc-0007Uy-Oe
	for qemu-devel@nongnu.org; Sun, 19 Oct 2008 05:05:01 -0400
Received: from [199.232.76.173] (port=48706 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KrUBf-0006vp-K1
	for qemu-devel@nongnu.org; Sun, 19 Oct 2008 05:03:00 -0400
Received: from mx2.redhat.com ([66.187.237.31]:49904)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1KrUBe-0001in-2V
	for qemu-devel@nongnu.org; Sun, 19 Oct 2008 05:02:58 -0400
Message-ID: <48FAF751.8010806@redhat.com>
Date: Sun, 19 Oct 2008 11:01:05 +0200
From: Avi Kivity <avi@redhat.com>
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>
	<48F1CD76.2000203@redhat.com> <20081017132040.GK19428@kernel.dk>
In-Reply-To: <20081017132040.GK19428@kernel.dk>
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: Jens Axboe <qemu@kernel.dk>
Cc: Chris Wright <chrisw@redhat.com>, Mark McLoughlin <markmc@redhat.com>, kvm-devel <kvm-devel@lists.sourceforge.net>, Laurent Vivier <Laurent.Vivier@bull.net>, qemu-devel@nongnu.org, Ryan Harper <ryanh@us.ibm.com>

Jens Axboe wrote:
> On Sun, Oct 12 2008, Avi Kivity wrote:
>   
>>> If you have a normal laptop, your disk has a cache.  That cache does 
>>> not have a battery backup.  Under normal operations, the cache is 
>>> acting in write-back mode and when you do a write, the disk will 
>>> report the write as completed even though it is not actually on disk.  
>>> If you really care about the data being on disk, you have to either 
>>> use a disk with a battery backed cache (much more expensive) or enable 
>>> write-through caching (will significantly reduce performance).
>>>
>>>       
>> I think that with SATA NCQ, this is no longer true.  The drive will 
>> report the write complete when it is on disk, and utilize multiple 
>> outstanding requests to get coalescing and reordering.  Not sure about 
>>     
>
> It is still very true. Go buy any consumer drive on the market and check
> the write cache settings - hint, it's definitely shipped with write back
> caching. So while the drive may have NCQ and Linux will use it, the
> write cache is still using write back unless you explicitly change it.
>
>   

Sounds like a bug.  Shouldn't Linux disable the write cache unless the 
user explicitly enables it, if NCQ is available?  NCQ should provide 
acceptable throughput even without the write cache.


-- 
error compiling committee.c: too many arguments to function