From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Kre14-0003z5-EF
	for qemu-devel@nongnu.org; Sun, 19 Oct 2008 15:32:42 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Kre12-0003yt-VV
	for qemu-devel@nongnu.org; Sun, 19 Oct 2008 15:32:42 -0400
Received: from [199.232.76.173] (port=50369 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Kre12-0003yq-Pg
	for qemu-devel@nongnu.org; Sun, 19 Oct 2008 15:32:40 -0400
Received: from mx2.redhat.com ([66.187.237.31]:43405)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <avi@redhat.com>) id 1Kre12-00086l-HT
	for qemu-devel@nongnu.org; Sun, 19 Oct 2008 15:32:40 -0400
Message-ID: <48FB8B2C.6010908@redhat.com>
Date: Sun, 19 Oct 2008 21:31:56 +0200
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [RFC] Disk integrity in QEMU
References: <48FAF751.8010806@redhat.com>	<20081019181026.GU19428@kernel.dk>	<48FB7B26.2090903@redhat.com>
	<20081019.131707.1678758304.imp@bsdimp.com>
In-Reply-To: <20081019.131707.1678758304.imp@bsdimp.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: "M. Warner Losh" <imp@bsdimp.com>
Cc: chrisw@redhat.com, markmc@redhat.com, kvm-devel@lists.sourceforge.net, Laurent.Vivier@bull.net, qemu-devel@nongnu.org, ryanh@us.ibm.com

M. Warner Losh wrote:
> In message: <48FB7B26.2090903@redhat.com>
>             Avi Kivity <avi@redhat.com> writes:
> : >> 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.
> : >>     
> : >
> : > How can it be a bug? 
> : 
> : If it puts my data at risk, it's a bug.  I can understand it for IDE,
> : but not for SATA with NCQ.
>
> So wouldn't async mounts by default be a bug too?
>   

No.  Applications which are worried about data integrity use fsync() or 
backups to protect the user.

I'm not worried about losing a few minutes of openoffice.org work.  I'm 
worried about mail systems, filesystem metadata, etc. which can easily 
lose a large amount of data which is hard to recover.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.