From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KamVM-0001cH-5r for qemu-devel@nongnu.org; Wed, 03 Sep 2008 03:10:16 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KamVK-0001Yq-Ae for qemu-devel@nongnu.org; Wed, 03 Sep 2008 03:10:15 -0400 Received: from [199.232.76.173] (port=34116 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KamVK-0001YR-3U for qemu-devel@nongnu.org; Wed, 03 Sep 2008 03:10:14 -0400 Received: from mx20.gnu.org ([199.232.41.8]:56840) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KamVJ-0004Tq-Kc for qemu-devel@nongnu.org; Wed, 03 Sep 2008 03:10:13 -0400 Received: from ecfrec.frec.bull.fr ([129.183.4.8]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KamVI-0001j3-Hu for qemu-devel@nongnu.org; Wed, 03 Sep 2008 03:10:12 -0400 Subject: Re: [Qemu-devel][PATCH,RFC] Zero cluster dedup From: Laurent Vivier In-Reply-To: References: Content-Type: text/plain; charset=UTF-8 Date: Wed, 03 Sep 2008 09:09:35 +0200 Message-Id: <1220425775.4159.6.camel@frecb07144> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Shahar Frank Le mardi 02 septembre 2008 =C3=A0 09:28 -0700, Shahar Frank a =C3=A9crit = : > Hi All, >=20 > The following patch is implementing a zero cluster dedup feature to > the qcow2 image format. >=20 > The incentive for this feature is the image COW "inflation" problem > (i.e. COW image growth). The causes for the COW image pollution are > many; for example, Windows with NTFS do not reuse recently > de-allocated space and by that pollute many blocks. A na=C3=AFve soluti= on > would be to identify de-allocated space and de-allocate it from the > image block space. The problems with this approach are that 1) this > requires a windows side interface to the image, and 2) there is no > de-allocate verb for the images. >=20 > The suggested solution is simple: > 1) Use windows side cleanup/wipe utilities such as "Erase" "Free Wipe > Wizard" or "Disk Redactor" (or any other free/non free wipe utility) > to periodically wipe free space and cleanup temporaries. Most > utilities can be used to write *zeros* on the wiped blocks.=20 > 2) Make qcow2 to identify zero cluster writes and use them as > de-allocation hints (or "make hole" verb). To implement such feature > with minimal effort and minimal changes, I suggest to use the internal > COW mechanism of the qcow2 to create a shared zero cluster. To avoid > image format changes, such page is created on demand and then can be > shared with all zero writes. A non zero write on the zero cluster will > cause a normal COW operation (similar to the shared kernel zero > page).=20 Is it really needed to have a shared zero page ? When I read qcow_read() and qcow_aio_read_cb() I see: if (!cluster_offset) { ... memset(buf, 0, 512 * n); ... } and so I think you have just to clear the l2_table entry for the given clusters (and free them). Regards, Laurent --=20 ----------------- Laurent.Vivier@bull.net ------------------ "La perfection est atteinte non quand il ne reste rien =C3=A0 ajouter mais quand il ne reste rien =C3=A0 enlever." Saint Exup=C3=A9ry