qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: [RFC][STABLE 0.13] Revert "qcow2: Use bdrv_(p)write


From: Kevin Wolf
Subject: Re: [Qemu-devel] Re: [RFC][STABLE 0.13] Revert "qcow2: Use bdrv_(p)write_sync for metadata writes"
Date: Tue, 24 Aug 2010 14:35:06 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100720 Fedora/3.0.6-1.fc12 Thunderbird/3.0.6

Am 24.08.2010 14:27, schrieb Avi Kivity:
>   On 08/24/2010 03:21 PM, Alexander Graf wrote:
>> Avi Kivity wrote:
>>>   On 08/24/2010 03:12 PM, Alexander Graf wrote:
>>>>> Well, safety is not boolean. Considering to make it mostly safe instead
>>>>> of completely safe because of the performance doesn't mean that we
>>>>> should make it completely unsafe.
>>>>>
>>>> What is safety then? A vague feeling of "oh today is monday so my data
>>>> is safe, but on tuesday I always lose my image data"? Either we promise
>>>> to keep data safe or we don't. There is no in between.
>>>>
>>> Do you drive a car?
>> Would you buy a car where the breaks are known to not always work? ;)
> 
> That's not the case, even with cache=unsafe.
> 
>>> Though in general I agree we shouldn't compromise on data integrity.
>> That's my point. Either we go for it or we don't.
> 
> I don't know how bad the performance regression is, and how large the 
> integrity risk is.  I'd default towards preserving integrity, but maybe 
> this situation is different.

I have reports of installations taking like 50 min instead of 14 min. My
own qemu-io based test goes up from 1 s to 23 s. And I think the winner
is Michael's image conversion which went up from 30 s to 49 min.

So it's not like we're talking about just some 10 or 20 percent.

Kevin



reply via email to

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