qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Default cache mode


From: Kevin Wolf
Subject: Re: [Qemu-devel] Default cache mode
Date: Wed, 29 Jun 2011 16:11:53 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Thunderbird/3.1.10

Am 29.06.2011 15:53, schrieb Frediano Ziglio:
> 2011/6/29 Anthony Liguori <address@hidden>:
>> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]