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

[Kevin Wolf <kwolf@redhat.com>]

Am 26.05.2010 16:08, schrieb Anthony Liguori:
> On 05/26/2010 09:03 AM, Kevin Wolf wrote:
>> Am 26.05.2010 15:42, schrieb Anthony Liguori:
>>    
>>> On 05/26/2010 03:43 AM, Kevin Wolf wrote:
>>>      
>>>> Am 26.05.2010 03:31, schrieb Anthony Liguori:
>>>>
>>>>        
>>>>> 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 also be
>>>>> removable via a ./configure option because no sane distribution should
>>>>> enable this for end users.
>>>>>
>>>>>          
>>>> We know better what you stupid user want?
>>>>        
>>> What percentage of qemu users do you think have actually read qemu-doc.texi?
>>>      
>> As I said, put the warning in the option name like cache=unsafe or
>> something even more scary and I'm all for it.
>>
>>    
>>> It's not a stretch for someone to have heard that cache options can
>>> improve performance, and then see cache=volatile in the help output, try
>>> it, and then start using it because they observe a performance improvement.
>>>
>>> That's not being stupid.  I think it's a reasonable expectation for a
>>> user to have that their data is safe.
>>>      
>> You seem to think that the user is too stupid to allow him to use this
>> option even if he's perfectly aware what it's doing. It's a useful
>> option if it's used right.
>>    
> 
> No, that's not what I said.  I'm saying we need to try hard to make a 
> user aware of what they're doing.
> 
> If it spit out a warning on stdio, I wouldn't think a compile option is 
> needed.  Even with help output text, I'm concerned that someone is going 
> to find a bad example on the internet.
> 
> cache=unsafe addresses the problem although I think it's a bit hokey.

Then let's do it this way. I'm not opposed to a stdio message either,
even though I don't think it's really necessary with a name like
cache=unsafe. I just say that disabling the option is not a solution
because it prevents valid use.

>> We need to make clear that it's dangerous when it's used in the wrong
>> cases (for example by naming), but just disabling is not a solution for
>> that. You don't suggest that "no sane distribution" should ship rm,
>> because it's dangerous if you use it wrong, do you?
>>    
> 
> You realize that quite a lot of distributions carry a patch to rm that 
> prevents a user from doing rm -rf /?

Most rm invocations that I regretted later were not rm -rf /. Actually,
I think rm -rf / is not among them at all. ;-)

And I seem to remember that even these rm patches still allow the
protection to be overridden by some force flag. But I've never tried it out.

Kevin