Re: [Qemu-devel] Re: [PATCH] Add cache=volatile parameter to -drive

[Aurelien Jarno <aurelien@aurel32.net>]

Anthony Liguori a écrit :
> On 05/26/2010 03:52 AM, Aurelien Jarno wrote:
>> On Tue, May 25, 2010 at 08:31:20PM -0500, Anthony Liguori wrote:
>>    
>>> On 05/25/2010 04:01 PM, Aurelien Jarno wrote:
>>>      
>>>> I really think this patch can be useful, in my own case when testing
>>>> debian-installer (I already cache=writeback). In short all that is about
>>>> developing and testing, as opposed to run a VM in production, can
>>>> benefit about that. This was one of the original use case of QEMU before
>>>> KVM arrived.
>>>>
>>>> Unless someone can convince me not to do it, I seriously considering
>>>> applying this patch.
>>>>        
>>> There really needs to be an indication in the --help output of what
>>> the ramifications of this option are, in the very least.  It should
>>>      
>> That's indeed something than can be done, but to avoid double standards,
>> it should also be done for other features that can lead to data
>> corruption. I am talking for example on the qcow format, which is not
>> really supported anymore.
>>    
> 
> I agree.
> 
>>> also be removable via a ./configure option because no sane
>>> distribution should enable this for end users.
>>>
>>>      
>> I totally disagree. All the examples I have given apply to qemu *users*,
>> not qemu developers. They surely don't want to recompile qemu for their
>> usage. Note also that what is proposed in this patch was the default not
>> too long ago, and that a lot of users complained about the new default
>> for their usage, they see it as a regression. We even had to put a note
>> explaining that in the Debian package to avoid to many bug reports.
>> cache=writeback only answer partially to this use case.
>>    
> 
> It's hard for me to consider this a performance regression because 
> ultimately, you're getting greater than bare metal performance (because 
> of extremely aggressive caching).  It might be a regression from the 
> previous performance, but that was at the cost of safety.

For people who don't care about safety it's still a regression. And it
is a common usage of QEMU.

> We might get 100 bug reports about this "regression" but they concern 
> much less than 1 bug report of image corruption because of power 
> failure/host crash.  A reputation of being unsafe is very difficult to 
> get rid of and is something that I hear concerns about frequently.
>
> I'm not suggesting that the compile option should be disabled by default 
> upstream.  But the option should be there for distributions because I 
> hope that any enterprise distro disables it.
> 

Which basically means those distro don't care about some use cases of
QEMU, that were for most of them the original uses cases. It's sad.

Sometimes I really whishes that KVM never tried to reintegrate code into
QEMU, it doesn't bring only good things.

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net