From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KasAM-0001gh-05
	for qemu-devel@nongnu.org; Wed, 03 Sep 2008 09:12:58 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KasAL-0001fw-8V
	for qemu-devel@nongnu.org; Wed, 03 Sep 2008 09:12:57 -0400
Received: from [199.232.76.173] (port=46273 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KasAL-0001fk-3o
	for qemu-devel@nongnu.org; Wed, 03 Sep 2008 09:12:57 -0400
Received: from ecfrec.frec.bull.fr ([129.183.4.8]:58085)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <Laurent.Vivier@bull.net>) id 1KasAL-0002pT-JC
	for qemu-devel@nongnu.org; Wed, 03 Sep 2008 09:12:57 -0400
Subject: RE: [Qemu-devel][PATCH,RFC] Zero cluster dedup
From: Laurent Vivier <Laurent.Vivier@bull.net>
In-Reply-To: <ED2414DB5FBBCF4FA66ECE71F290E9A29B81E0@EXVBE011-2.exch011.intermedia.net>
References: <ED2414DB5FBBCF4FA66ECE71F290E9A29B81E0@EXVBE011-2.exch011.intermedia.net>
Content-Type: text/plain; charset=utf-8
Date: Wed, 03 Sep 2008 15:12:38 +0200
Message-Id: <1220447558.4189.22.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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/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: Shahar Frank <shaharf@qumranet.com>
Cc: Kevin Wolf <kwolf@suse.de>, qemu-devel@nongnu.org

Le mercredi 03 septembre 2008 =C3=A0 06:07 -0700, Shahar Frank a =C3=A9cr=
it :
> > This is still the L2 table which has to be written each time. Say we
> > have a 64k write, then you could save 15 L2 table writes if qcow_dedu=
p
> > could handle zeroing multiple contiguous clusters at once. This could
> > matter for performance when wiping lots of data.
>=20
> You have a good point when it comes to a sequence of zero clusters (the
> L2 writes can be optimized as you wrote above). I will re-implement
> this.

Perhaps you should consider to set the l2_table entry to 0 when there is
no backing file: it avoids some I/O and allows to aggregate free
entries.
(no, I'm not obstinate :-D )

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