Re: [Qemu-devel] Default cache mode

[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.

Lately I'm doing some extensive testing on image performance and I
noted that are not only image dependent but also filesystem (where
image is stored) dependent but when data are allocated speed is good.
raw disks are not so fast as expected? Try to use fallocate command to
allocate the file than do a dd to fill the entire file with zeros and
writethrough will perform very well. Allocating raw with qemu-img lead
to a normal sparse file which written with O_DSYNC flag is quite slow
due to extents allocation and fragmentation.

Regards
 Frediano Ziglio