From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KaniA-0002Ji-O9 for qemu-devel@nongnu.org; Wed, 03 Sep 2008 04:27:34 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kani8-0002Hl-7v for qemu-devel@nongnu.org; Wed, 03 Sep 2008 04:27:33 -0400 Received: from [199.232.76.173] (port=36222 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kani7-0002Hb-Vk for qemu-devel@nongnu.org; Wed, 03 Sep 2008 04:27:32 -0400 Received: from ecfrec.frec.bull.fr ([129.183.4.8]:39446) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kani7-0007cq-DZ for qemu-devel@nongnu.org; Wed, 03 Sep 2008 04:27:32 -0400 Subject: Re: [Qemu-devel][PATCH,RFC] Zero cluster dedup From: Laurent Vivier In-Reply-To: <48BE473C.4090102@suse.de> References: <1220428776.4159.12.camel@frecb07144> <48BE473C.4090102@suse.de> Content-Type: text/plain; charset=utf-8 Date: Wed, 03 Sep 2008 10:25:37 +0200 Message-Id: <1220430337.4159.14.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: Kevin Wolf Cc: qemu-devel@nongnu.org, Shahar Frank Le mercredi 03 septembre 2008 =C3=A0 10:13 +0200, Kevin Wolf a =C3=A9crit= : > Laurent Vivier schrieb: > > Le mercredi 03 septembre 2008 =C3=A0 00:35 -0700, Shahar Frank a =C3=A9= crit : > >>> 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). > >> You are correct if this is a standalone image i.e. without backing > >> file. If the image has a backing file, a zero mapping is interpreted > >> as "read it from the backing file at the same (logical) offset".=20 > >=20 > > I think backing file is also qcow2, so if you write all zeros the > > behavior will be the same, and read from the backing file will use al= so > > memset(). >=20 > Not if the cluster is already used in the backing file. Then you would > write 0 to the L2 table of the image itself but not to the L2 table of > the backing file (if you did, it would be a bug). So a read would > operate on the old allocation of the backing file rather than on zeros. Yes, you're right. 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