From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KanUw-0001Uj-SF
	for qemu-devel@nongnu.org; Wed, 03 Sep 2008 04:13:54 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KanUv-0001U9-6O
	for qemu-devel@nongnu.org; Wed, 03 Sep 2008 04:13:54 -0400
Received: from [199.232.76.173] (port=54416 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KanUu-0001U2-RF
	for qemu-devel@nongnu.org; Wed, 03 Sep 2008 04:13:52 -0400
Received: from ns.suse.de ([195.135.220.2]:49385 helo=mx1.suse.de)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <kwolf@suse.de>) id 1KanUu-0005M9-P1
	for qemu-devel@nongnu.org; Wed, 03 Sep 2008 04:13:52 -0400
Message-ID: <48BE473C.4090102@suse.de>
Date: Wed, 03 Sep 2008 10:13:48 +0200
From: Kevin Wolf <kwolf@suse.de>
MIME-Version: 1.0
Subject: Re: [Qemu-devel][PATCH,RFC] Zero cluster dedup
References: <ED2414DB5FBBCF4FA66ECE71F290E9A29B8143@EXVBE011-2.exch011.intermedia.net>
	<1220428776.4159.12.camel@frecb07144>
In-Reply-To: <1220428776.4159.12.camel@frecb07144>
Content-Type: text/plain; charset=UTF-8
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: Laurent Vivier <Laurent.Vivier@bull.net>
Cc: qemu-devel@nongnu.org, Shahar Frank <shaharf@qumranet.com>

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 also
> memset().

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.

Kevin