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 15:11:40 +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:00, schrieb Avi Kivity:
> On 06/29/2011 02:59 PM, 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, and most people
>> don't use it if they know that it can be changed because it just
>> performs too bad. There are use cases where you need it (broken guest
>> OS), but none and writeback are just as correct with respect to the
>> specs and they are safe to use with current OSes. And even with broken
>> OSes, in many use cases it doesn't really matter if you lose a VM  and
>> have to reinstall it (which is probably true even more for users
>> invoking qemu directly instead of using libvirt).
>>
>> I think the motivation to switch from writeback to writethrough as
>> default was that writeback was entirely unsafe back then. This isn't
>> true any more, so is there still enough reason to have the slow
>> writethrough mode as default?
>>
>> I'm not entirely sure if I should suggest writeback or none as the new
>> default, but I think it could make sense to change it.
> 
> So long as -M old retains the old behaviour, I'm in favour.

Means that we need to move the WCE flag into guest state first, but
that's what Anthony suggested, too. So I think we can do that.

> I think writeback is probably a better default than none.

Alex had a good point that O_DIRECT doesn't work everywhere, so I agree.

Kevin



reply via email to

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