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

[Kevin Wolf <kwolf@redhat.com>]

Am 21.02.2011 16:16, schrieb Anthony Liguori:
> On 02/21/2011 08:10 AM, Kevin Wolf wrote:
>> Am 21.02.2011 14:44, schrieb Stefan Hajnoczi:
>>    
>>> On Mon, Feb 21, 2011 at 8:59 AM, Kevin Wolf<kwolf@redhat.com>  wrote:
>>>      
>>>> In fact, the only area where qcow2 in performs really bad in 0.14 is
>>>> cache=writethrough (which unfortunately is the default...). With
>>>> cache=none it's easy to find scenarios where it provides higher
>>>> throughput than QED.
>>>>        
>>> Yeah, I'm tempted to implement parallel allocating writes now so I can
>>> pick on qcow2 in all benchmarks again ;).
>>>      
>> Heh. ;-)
>>
>> In the end it just shows that the differences are mainly in the
>> implementation, not in the format.
>>
>>    
>>>> Anyway, there's really only one crucial difference between QED and
>>>> qcow2, which is that qcow2 ensures that metadata is consistent on disk
>>>> at any time whereas QED relies on a dirty flag and rebuilds metadata
>>>> after a crash (basically requiring an fsck). The obvious solution if you
>>>> want to have this in qcow2, is adding a dirty flag there as well.
>>>>
>>>> Likewise, I think FVD might provide some ideas that we can integrate as
>>>> well, I just don't see a justification to include it as a separate format.
>>>>        
>>> You think that QED and FVD can be integrated into a QCOW2-based
>>> format.  I agree it's possible and has some value.  It isn't pretty
>>> and I would prefer to work on a clean new format because that, too,
>>> has value.
>>>
>>> In any case, the next step is to get down to specifics.  Here is the
>>> page with the current QCOW3 roadmap:
>>>
>>> http://wiki.qemu.org/Qcow3_Roadmap
>>>
>>> Please raise concrete requirements or features so they can be
>>> discussed and captured.
>>>
>>> For example, journalling is an alternative to the dirty bit approach.
>>> If you feel that journalling is the best technique to address
>>> consistent updates, then make your case outside the context of today's
>>> qcow2, QED, and FVD implementations (although benchmark data will rely
>>> on current implementations).  Explain how the technique would fit into
>>> QCOW3 and what format changes need to be made.
>>>      
>> I think journalling is an interesting option, but I'm not sure if we
>> should target it for 0.15. As you know, there's already more than enough
>> stuff to do until then, with coroutines etc. The dirty flag thing would
>> be way easier to implement. We can always add a journal as a compatible
>> feature in 0.16.
>>
>> To be honest, I'm not even sure any more that the dirty flag is that
>> important. Originally we have been talking about cache=none and it
>> definitely makes a big difference there because we save flushes.
>> However, we're talking about cache=writethrough now and you flush on any
>> write. It might be more important to make things parallel for writethrough.
>>    
> 
> One thing I wonder about is whether we really need to have cache=X and 
> wce=X.  I never really minded the fact that cache=none advertised wce=on 
> because we behaved effectively as if wce=on.  But now that qcow2 
> triggers on wce=on, I'm a bit concerned that we're introducing a subtle 
> degradation that most people won't realize.
> 
> Ignoring some of the problems with O_DIRECT, semantically, I think 
> there's a strong use-case for cache=none, wce=off.

Fully agree, there's no real reason for having three writeback modes,
but only one writethrough mode. It should be completely symmetrical.

I think Christoph has mentioned several times that he has some patches
for this. What's the status of them, Christoph?

Kevin