qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Kevin Wolf
Subject: Re: [Qemu-devel] Re: Strategic decision: COW format
Date: Wed, 23 Feb 2011 15:38:10 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10

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

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

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]