[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] Disk integrity in QEMU
From: |
Avi Kivity |
Subject: |
Re: [Qemu-devel] [RFC] Disk integrity in QEMU |
Date: |
Sun, 19 Oct 2008 20:24:58 +0200 |
User-agent: |
Thunderbird 2.0.0.16 (X11/20080723) |
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.
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU, (continued)
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Laurent Vivier, 2008/10/14
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Avi Kivity, 2008/10/16
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Izik Eidus, 2008/10/13
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Avi Kivity, 2008/10/14
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Avi Kivity, 2008/10/12
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Jens Axboe, 2008/10/17
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Avi Kivity, 2008/10/19
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Jens Axboe, 2008/10/19
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU,
Avi Kivity <=
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Jens Axboe, 2008/10/19
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Avi Kivity, 2008/10/19
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Jens Axboe, 2008/10/19
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Avi Kivity, 2008/10/19
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Avi Kivity, 2008/10/20
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Avi Kivity, 2008/10/19
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU, M. Warner Losh, 2008/10/19
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Avi Kivity, 2008/10/19
Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Fabrice Bellard, 2008/10/10
Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Laurent Vivier, 2008/10/13