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

[Anthony Liguori <anthony@codemonkey.ws>]

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.

>> 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.

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.

Regards,

Anthony Liguori

> What are the points where you think that performance of internal
> snapshots suffers?
>
> The argument that I would understand is that internal snapshots are
> probably not as handy in all scenarios.
>
> Kevin
>
>