Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format

[Kevin Wolf <kwolf@redhat.com>]

Am 08.09.2010 15:26, schrieb Anthony Liguori:
> On 09/08/2010 08:20 AM, Kevin Wolf wrote:
>> Am 08.09.2010 14:48, schrieb Anthony Liguori:
>>>>> I think one of the critical flaws in qcow2 was trying to invent a
>>>>> better filesystem within qemu instead of just sticking to a very
>>>>> simple and obviously correct format and letting the FS folks do the
>>>>> really fancy stuff.
>>>>>          
>>>> Well, if we introduce a minimal format, we need to make sure it isn't
>>>> too minimal.
>>>>
>>>> I'm still not sold on the idea.  What we're doing now is pushing the
>>>> qcow2 complexity to users.  We don't have to worry about refcounts
>>>> now, but users have to worry whether they're the machine they're
>>>> copying the image to supports qed or not.
>>>>
>>>> The performance problems with qcow2 are solvable.  If we preallocate
>>>> clusters, the performance characteristics become essentially the same
>>>> as qed.
>>>>        
>>> By creating two code paths within qcow2.  It's not just the reference
>>> counts, it's the lack of guaranteed alignment, compression, and some of
>>> the other poor decisions in the format.
>>>      
>> I'm not aware of any unaligned data in qcow2. Compression can leave some
>> sectors sparse, but that's something the FS has to deal with, not qcow2.
>>    
> 
> If my memory serves, you changed qcow2 some time ago to make sure that 
> metadata is aligned but historically, we didn't always do that and the 
> qcow2 doesn't enforce that metadata is aligned.

I can't remember any such change, but the problem might as well be on my
side. In any case, if it was like you say, we would still have to accept
unaligned data or we would have broken compatibility.

Maybe you mean that historically the qcow2 driver was accessing single
table entries instead of the whole table, and that was an unaligned
access? That was only a bad implementation, though.

> This means that if you did try to make a version of qcow2 that was 
> totally async or really just was fast, you'd have to make sure you dealt 
> with unaligned accesses and bounced buffers accordingly.

Right. Though even if some obscure data was unaligned, what really
matters are L1/L2 tables and refcount tables/blocks. And these are
definitely cluster aligned.

>>> If you have two code paths in qcow2, you have non-deterministic
>>> performance because users that do reasonable things with their images
>>> will end up getting catastrophically bad performance.
>>>      
>> Compression and encryption lead to bad performance, yes. These are very
>> clear criteria and something very easy to understand for users. I've
>> never heard any user complain about this "non-deterministic" behaviour.
> 
> That's because qcow2 has always been limited in it's performance so it's 
> quite deterministic :-)

Run an installation on an encrypted qcow2 and one on a "normal" qcow2
image. Last time I tried there was a bit of a difference...

Kevin