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

[Kevin Wolf <kwolf@redhat.com>]

Am 23.02.2011 16:29, schrieb Anthony Liguori:
> On 02/23/2011 08:38 AM, Kevin Wolf wrote:
>> Am 23.02.2011 15:23, schrieb Anthony Liguori:
>>    
>>> On 02/23/2011 07:43 AM, Avi Kivity wrote:
>>>      
>>>> On 02/22/2011 10:56 AM, Kevin Wolf wrote:
>>>>        
>>>>> *sigh*
>>>>>
>>>>> It starts to get annoying, but if you really insist, I can repeat it
>>>>> once more: These features that you don't need (this is the correct
>>>>> description for what you call "misfeatures") _are_ implemented in a way
>>>>> that they don't impact the "normal" case. And they are it today.
>>>>>
>>>>>          
>>>> Plus, encryption and snapshots can be implemented in a way that
>>>> doesn't impact performance more than is reasonable.
>>>>        
>>> We're still missing the existence proof of this, but even assuming it
>>>      
>> Define "reasonable". I sent you some numbers not too long for
>> encryption, and I consider them reasonable (iirc, between 25% and 40%
>> slower than without encryption).
>>    
> 
> I was really referring to snapshots.  I have absolutely no doubt that 
> encryption can be implemented with a reasonable performance overhead.

Alright. Last time you complained about things being too slow you were
explicitly referring to encryption, so sometimes it's hard for me to
follow you jumping from once topic to another.

>>> existed, what about snapshots?  Are we okay having a feature in a
>>> prominent format that isn't going to meet user's expectations?
>>>
>>> Is there any hope that an image with 1000, 1000, or 10000 snapshots is
>>> going to have even reasonable performance in qcow2?
>>>      
>> Is there any hope for backing file chains of 1000 files or more? I
>> haven't tried it out, but in theory I'd expect that internal snapshots
>> could cope better with it than external ones because internal snapshots
>> don't have to go through the whole chain all the time.
> 
> I don't think there's a user expectation of backing file chains of 1000 
> files performing well.  However, I've talked to a number of customers 
> that have been interested in using internal snapshots for checkpointing 
> which would involve a large number of snapshots.

So if there's no expectation that a chain of 1000 external snapshots
works fine, why is it a requirement for internal snapshots?

You might have a point if the external snapshots were actually not a
chain, but a snapshot tree with lots of branches, but checkpointing
means exactly creating a single chain.

That said, while I haven't tried it out, I don't see any theoretical
problems with using 1000 internal snapshots.

> In fact, Fabrice originally added qcow2 because he was interested in 
> doing reverse debugging.  The idea of internal snapshots was to store a 
> high number of checkpoints to allow reverse debugging to be optimized.
> 
> I think the way snapshot metadata is stored makes this not realistic 
> since they're stored in more or less a linear array.  I think to really 
> support a high number of snapshots, you'd want to store a hash with each 
> block that contained a refcount > 1.  I think you quickly end up 
> reinventing btrfs though in the process.

I share Avi's problem here, I don't really understand what the problem
with a linear list of snapshots is.

Kevin