From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Krd18-000395-Ex for qemu-devel@nongnu.org; Sun, 19 Oct 2008 14:28:42 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Krd17-00038j-8b for qemu-devel@nongnu.org; Sun, 19 Oct 2008 14:28:42 -0400 Received: from [199.232.76.173] (port=58206 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Krd17-00038a-2K for qemu-devel@nongnu.org; Sun, 19 Oct 2008 14:28:41 -0400 Received: from mx2.redhat.com ([66.187.237.31]:52432) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Krd16-0001fT-JN for qemu-devel@nongnu.org; Sun, 19 Oct 2008 14:28:40 -0400 Message-ID: <48FB7B26.2090903@redhat.com> Date: Sun, 19 Oct 2008 20:23:34 +0200 From: Avi Kivity 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> <48FAF751.8010806@redhat.com> <20081019181026.GU19428@kernel.dk> In-Reply-To: <20081019181026.GU19428@kernel.dk> Content-Type: text/plain; charset=ISO-8859-1 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: Jens Axboe Cc: Chris Wright , Mark McLoughlin , kvm-devel , Laurent Vivier , qemu-devel@nongnu.org, Ryan Harper Jens Axboe wrote: >> 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. > Changing the cache policy of a drive would be a > policy decision in the kernel, If you don't want this in the kernel, then the system as a whole should default to being safe. Though in this case I think it is worthwhile to do this in the kernel. > that is never the right thing to do. > There's no such thing as 'acceptable throughput', I meant that performance is not completely destroyed. How can you even compare data safety to some percent of performance? > manufacturers and > customers usually just want the go faster stripes and data consistency > is second. What is the performance impact of disabling the write cache, given enough queue depth? > Additionally, write back caching is perfectly safe, if used > with a barrier enabled file system in Linux. > Not all Linux filesystems are barrier enabled, AFAIK. Further, barriers don't help with O_DIRECT (right?). I shouldn't need a disk array to run a database. > Also note that most users will not have deep queuing for most things. To > get good random write performance with write through caching and NCQ, > you naturally need to be able to fill the drive queue most of the time. > Most desktop workloads don't come close to that, so the user will > definitely see it as slower. > Most desktop workloads use writeback cache, so write performance is not critical. However I'd hate to see my data destroyed by a power failure, and today's large caches can hold a bunch of data. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.