From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=44630 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PsH0r-0007Kb-5n
	for qemu-devel@nongnu.org; Wed, 23 Feb 2011 10:52:26 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1PsH0p-0005fS-Rj
	for qemu-devel@nongnu.org; Wed, 23 Feb 2011 10:52:25 -0500
Received: from mail-vx0-f173.google.com ([209.85.220.173]:46651)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1PsH0p-0005fN-PV
	for qemu-devel@nongnu.org; Wed, 23 Feb 2011 10:52:23 -0500
Received: by vxb41 with SMTP id 41so2835837vxb.4
	for <qemu-devel@nongnu.org>; Wed, 23 Feb 2011 07:52:23 -0800 (PST)
Message-ID: <4D652CD3.5030806@codemonkey.ws>
Date: Wed, 23 Feb 2011 09:50:43 -0600
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] Re: Strategic decision: COW format
References: <OF3C9DAE9F.EC6B5878-ON85257826.00715C10-85257826.007A14FB@LocalDomain>	<OFF3B73D6C.D1225EB2-ON85257838.006A5FC5-85257838.006C65F3@us.ibm.com>	<4D5BC467.4070804@redhat.com>	<m3r5b53duy.fsf_-_@blackfin.pond.sub.org>	<4D5E4271.80501@redhat.com>	<4D5E8031.5020402@codemonkey.ws>	<m3fwrgpis0.fsf@blackfin.pond.sub.org>	<4D637A20.9020307@redhat.com>	<4D650F10.3060900@redhat.com>
	<4D651858.9040106@codemonkey.ws> <4D652675.1070908@redhat.com>
	<4D652868.8030908@codemonkey.ws> <4D6529A9.3090509@redhat.com>
In-Reply-To: <4D6529A9.3090509@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Avi Kivity <avi@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Chunqiang Tang <ctang@us.ibm.com>, qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>, Markus Armbruster <armbru@redhat.com>

On 02/23/2011 09:37 AM, Avi Kivity wrote:
> On 02/23/2011 05:31 PM, Anthony Liguori wrote:
>>>
>>>> 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?
>>>>
>>>
>>> Are thousands of snapshots for a single image a reasonable user 
>>> expectation?  What's the use case?
>>
>>
>> Checkpointing.  It was the original use-case that led to qcow2 being 
>> invented.
>
> I still don't see.  What would you do with thousands of checkpoints?

For reverse debugging, if you store checkpoints at a rate of save, every 
10ms, and then degrade to storing every 100ms after 1 second, etc. 
you'll have quite a large number of snapshots pretty quickly.  The idea 
of snapshotting with reverse debugging is that instead of undoing every 
instruction, you can revert to the snapshot before, and then replay the 
instruction stream until you get to the desired point in time.

For disaster recovery, there are some workloads that you can meaningful 
revert to a snapshot provided that the snapshot is stored at a rate of 
something frequency (like once a second).  Think of something like a 
webserver where the only accumulated data is logs.  Losing some of the 
logs is better than losing all of the logs.

Regards,

Anthony Liguori