From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54178 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PsGcM-0004rB-1H for qemu-devel@nongnu.org; Wed, 23 Feb 2011 10:27:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PsGc5-0008OF-MF for qemu-devel@nongnu.org; Wed, 23 Feb 2011 10:26:50 -0500 Received: from mx1.redhat.com ([209.132.183.28]:21835) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PsGc5-0008Nv-Ce for qemu-devel@nongnu.org; Wed, 23 Feb 2011 10:26:49 -0500 Message-ID: <4D652675.1070908@redhat.com> Date: Wed, 23 Feb 2011 17:23:33 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Strategic decision: COW format References: <4D5BC467.4070804@redhat.com> <4D5E4271.80501@redhat.com> <4D5E8031.5020402@codemonkey.ws> <4D637A20.9020307@redhat.com> <4D650F10.3060900@redhat.com> <4D651858.9040106@codemonkey.ws> In-Reply-To: <4D651858.9040106@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , Chunqiang Tang , qemu-devel@nongnu.org, Markus Armbruster , Stefan Hajnoczi On 02/23/2011 04:23 PM, Anthony Liguori wrote: > 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 > existed, dm-crypt isn't any more complicated, and it's used by default in most distributions these days. > 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? -- error compiling committee.c: too many arguments to function