From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=49064 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pz8r3-00016u-DO for qemu-devel@nongnu.org; Mon, 14 Mar 2011 10:34:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pz8oi-0005uB-Ll for qemu-devel@nongnu.org; Mon, 14 Mar 2011 10:32:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:25257) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pz8oi-0005t8-7Z for qemu-devel@nongnu.org; Mon, 14 Mar 2011 10:32:16 -0400 Message-ID: <4D7E2763.6050906@redhat.com> Date: Mon, 14 Mar 2011 15:34:11 +0100 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Strategic decision: COW format References: <4D5BC467.4070804@redhat.com> <4D5E4271.80501@redhat.com> <20110220221357.GO4580@hall.aurel32.net> <4D62295E.1030504@redhat.com> <4D7D036B.4050706@codemonkey.ws> <4D7E167A.1020509@codemonkey.ws> <4D7E22FF.3090803@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Chunqiang Tang Cc: Stefan Hajnoczi , Aurelien Jarno , Markus Armbruster , qemu-devel@nongnu.org Am 14.03.2011 15:25, schrieb Chunqiang Tang: >> IIUC, he already uses a refcount table. Actually, I think that a >> refcount table is a requirement to provide the interesting properties >> that internal snapshots have (see my other mail). >> >> Refcount tables aren't a very complex thing either. In fact, it makes a >> format much simpler to have one concept like refcount tables instead of >> adding another different mechanism for each new feature that would be >> natural with refcount tables. >> >> The only problem with them is that they are metadata that must be >> updated. However, I think we have discussed enough how to avoid the >> greatest part of that cost. > > FVD's novel uses of the reference count table reduces the metadata update > overhead down to literally zero during normal execution of a VM. This gets > the bests of QCOW2's reference count table but without its oeverhead. In > FVD, the reference count table is only updated when creating a new > snapshot or deleting an existing snapshot. The reference count table is > never updated during normal execution of a VM. Yeah, I think that's basically an interesting property. However, I don't think that it makes a big difference compared to qcow2's refcount table when you use a writeback metadata cache. What about the question that I had in my other mail? (How do you determine if a cluster is free without scanning the whole lookup table?) I think this might be the missing piece for me to understand how your approach works. Kevin