From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:59954)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benoit.canet@irqsave.net>) id 1TtJt8-0005lu-UL
	for qemu-devel@nongnu.org; Thu, 10 Jan 2013 10:17:58 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <benoit.canet@irqsave.net>) id 1TtJt7-00059r-II
	for qemu-devel@nongnu.org; Thu, 10 Jan 2013 10:17:50 -0500
Received: from nodalink.pck.nerim.net ([62.212.105.220]:35381
	helo=paradis.irqsave.net) by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benoit.canet@irqsave.net>) id 1TtJt7-00059e-8w
	for qemu-devel@nongnu.org; Thu, 10 Jan 2013 10:17:49 -0500
Date: Thu, 10 Jan 2013 16:18:12 +0100
From: =?iso-8859-1?Q?Beno=EEt?= Canet <benoit.canet@irqsave.net>
Message-ID: <20130110151812.GA3457@irqsave.net>
References: <20130109152443.GB3494@irqsave.net>
	<CAJSP0QVHY2XLyUw6-pGt8pf_S9XP0xe_e1LKKP-Yf3UvakxASQ@mail.gmail.com>
	<20130109163928.GC3494@irqsave.net>
	<CAJSP0QXvT=3L8NY+VebECwZeS4CSmFG3+F8h2scg2CrWsUdviQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <CAJSP0QXvT=3L8NY+VebECwZeS4CSmFG3+F8h2scg2CrWsUdviQ@mail.gmail.com>
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] QCOW2 deduplication design
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: =?iso-8859-1?Q?Beno=EEt?= Canet <benoit.canet@irqsave.net>, Kevin Wolf <kwolf@redhat.com>, qemu-devel <qemu-devel@nongnu.org>, Stefan Hajnoczi <stefanha@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>

> Now I understand.  This case covers overwriting existing data with new
> contents.  That is common :).
>=20
> But are you seeing a cluster with refcount > 1 being overwritten
> often?  If so, it's worth looking into why that happens.  It may be a
> common pattern for certain file systems or applications to write
> initial data 'A' first and then change it later.  This actually
> suggests against online dedup, or at least for something like qcow2
> delayed write where we don't "commit" yet because the guest will
> probably still modify or append to the data.

I apologize for the bogus former information.

The deduplication metrics accounting code was confusing the delete cluste=
r
operation with the more common hash removal from tree operation.
After fixing the metrics code commons files manipulations on the guest on=
ly
generate a few delete cluster operations.

The cases where a lots of cluster are deleted is when the image is overwr=
itten
with zeroes and reformating a partition with ext3.

Regards

Beno=EEt