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

[Anthony Liguori <anthony@codemonkey.ws>]

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.

Regards,

Anthony Liguori

> Maybe not writing out refcounts is something we should measure before we
> start implementing anything. (It's easy to disable all writes for a
> benchmark, even if the image will be broken afterwards)
>
>    
>> I think this is the level we need to discuss at rather than qcow2 vs QED vs FVD.
>>      
> Definitely more productive, yes.
>
> Kevin
>
>