qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: Strategic decision: COW format


From: Kevin Wolf
Subject: Re: [Qemu-devel] Re: Strategic decision: COW format
Date: Fri, 18 Feb 2011 22:27:31 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10

Am 18.02.2011 21:50, schrieb Anthony Liguori:
> On 02/18/2011 02:49 PM, Kevin Wolf wrote:
>> Am 18.02.2011 20:47, schrieb Anthony Liguori:
>>    
>>> On 02/18/2011 01:11 PM, Kevin Wolf wrote:
>>>      
>>>>> A new file format like fvd would be a challenge for the existing ones.
>>>>> Declare its support as unsupported or experimental, but let users
>>>>> decide which one is best suited to their needs!
>>>>>
>>>>>          
>>>> Basically this is what we did for QED. In hindsight I consider it a
>>>> mistake because it set a bad precedence of inventing something new
>>>> instead of fixing what's there.
>>>>        
>>> I don't see how qcow3 is fixing something that's there since it's still
>>> an incompatible format.
>>>
>>> It'd be a stronger argument if you were suggesting something that was
>>> still fully compatible with qcow2 but once compatibility is broken, it's
>>> broken.
>>>      
>> It's really more like adding an incompatible feature flag in QED. You
>> still have one implementation for old and new images instead of
>> splitting up development efforts, you still have all of the features and
>> so on.
> 
> In theory.  Since an implementation doesn't exist, we have no idea how 
> much code is actually going to be shared at the end of the day.
> 
> I suspect that, especially if you drop the ref table updates, there 
> won't be an awful lot of common code in the two paths.

Allowing refcounts to be inconsistent, protected by a dirty flag, is
only an option, and you should only take it if you absolutely need it
(i.e. your guest is broken and requires cache=writethrough, but you
desperately need performance)

My preferred way of implementing it is telling the refcount cache that
it should ignore flushes and write its data only back when another
refcount block must be loaded into the cache (which happens rarely
enough that it doesn't really hurt performance). This makes the
difference from the existing code more or less one if statement that
returns early.

Kevin



reply via email to

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