Re: [Qemu-devel] [RFC] Disk integrity in QEMU

[Avi Kivity <avi@redhat.com>]

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.