qemu-devel
[Top][All Lists]
Advanced

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

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


From: Kevin Wolf
Subject: Re: [Qemu-devel] Re: [PATCH] Add cache=volatile parameter to -drive
Date: Tue, 18 May 2010 09:42:03 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4

Am 17.05.2010 22:07, schrieb Jamie Lokier:
> Alexander Graf wrote:
>>
>> On 17.05.2010, at 18:26, Anthony Liguori wrote:
>>
>>> On 05/17/2010 11:23 AM, Paul Brook wrote:
>>>>>> I don't see a difference between the results. Apparently the barrier
>>>>>> option doesn't change a thing.
>>>>>>       
>>>>> Ok.  I don't like it, but I can see how it's compelling.  I'd like to
>>>>> see the documentation improved though.  I also think a warning printed
>>>>> on stdio about the safety of the option would be appropriate.
>>>>>     
>>>> I disagree with this last bit.
>>>>
>>>> Errors should be issued if the user did something wrong.
>>>> Warnings should be issued if qemu did (or will soon do) something other 
>>>> than
>>>> what the user requested, or otherwise made questionable decisions on the
>>>> user's behalf.
>>>>
>>>> In this case we're doing exactly what the user requested. The only 
>>>> plausible
>>>> failure case is where a user is blindly trying options that they clearly 
>>>> don't
>>>> understand or read the documentation for. I have zero sympathy for 
>>>> complaints
>>>> like "Someone on the Internet told me to use --breakme, and broke thinks".
>>>>   
>>>
>>> I see it as the equivalent to the Taint bit in Linux.  I want to make it 
>>> clear to users up front that if you use this option, and you have data loss 
>>> issues, don't complain.
>>>
>>> Just putting something in qemu-doc.texi is not enough IMHO.  Few people 
>>> actually read it.
>>
>> But that's why it's no default and also called "volatile". If you prefer, we 
>> can call it cache=destroys_your_image.
> 
> With that semantic, a future iteration of cache=volatile could even
> avoid writing to the backing file at all, if that's yet faster.  I
> wonder if that would be faster.  Anyone fancy doing a hack with the
> whole guest image as a big malloc inside qemu?  I don't have enough RAM :-)

But then you'd probably want a separate RAM block driver instead of
messing with cache options.

Kevin



reply via email to

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