Re: [Qemu-devel] Default cache mode

[Kevin Wolf <kwolf@redhat.com>]

Am 29.06.2011 15:53, schrieb Frediano Ziglio:
> 2011/6/29 Anthony Liguori <anthony@codemonkey.ws>:
>> On 06/29/2011 07:16 AM, Kevin Wolf wrote:
>>>
>>> Am 29.06.2011 14:06, schrieb Anthony Liguori:
>>>>
>>>> On 06/29/2011 06:59 AM, Kevin Wolf wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I think we have touched this topic before during some IRC discussions or
>>>>> somewhere deep in a mailing list thread, but I think it hasn't been
>>>>> discussed on the list.
>>>>>
>>>>> Our default cache mode of cache=writethrough is extremely conservative
>>>>> and provides absolute safety at the cost of performance,
>>>>
>>>> But for the most part, we track bare metal fairly well in terms of block
>>>> performance, no?
>>>>
>>>> Or are you really referring to qcow2 as a specific example?  In the
>>>> past, we used a different default caching mode for qcow2.  I think that
>>>> could be done again if there was a compelling reason.
>>>
>>> No, people are also complaining about bad performance with raw. Which
>>> isn't really surprising when you do a flush after each single write
>>> request. O_SYNC is really much more than is needed in the average case.
>>
>> Which file system on the host?
>>
>> At any rate, I'm a big fan of making wce tunable in the guest and then I
>> think setting wce=1 is quite reasonable to do by default.
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>>
>>> Kevin
>>
>>
>>
> 
> Personally I think default lead to poor performance but currently
> people know that even critical application are handled correctly.
> Assuming a client connect to a database server on a qemu guest when
> server reply "transaction ok" you know that even a host crash lead to
> a successful transaction. At least the fact that this assumption won't
> be true has to be stated.

If the guest is acting correctly, then this assumption is definitely
true with cache=none/writeback. What needs to happen is that the guest
issues a disk flush before sending your "transaction ok" message. If it
doesn't do that it can fail even on real hardware. cache=writethrough
makes things safe that aren't even safe on real hardware, that's why I
consider it extremely conservative.

Kevin