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

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

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