From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:49969)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benoit.canet@irqsave.net>) id 1Tr8Zr-0007pU-4g
	for qemu-devel@nongnu.org; Fri, 04 Jan 2013 09:48:56 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <benoit.canet@irqsave.net>) id 1Tr8Zq-0007ak-5A
	for qemu-devel@nongnu.org; Fri, 04 Jan 2013 09:48:55 -0500
Received: from nodalink.pck.nerim.net ([62.212.105.220]:56986
	helo=paradis.irqsave.net) by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benoit.canet@irqsave.net>) id 1Tr8Zp-0007aF-T2
	for qemu-devel@nongnu.org; Fri, 04 Jan 2013 09:48:54 -0500
Date: Fri, 4 Jan 2013 15:49:14 +0100
From: =?iso-8859-1?Q?Beno=EEt?= Canet <benoit.canet@irqsave.net>
Message-ID: <20130104144914.GA3406@irqsave.net>
References: <1357143393-29832-1-git-send-email-benoit@irqsave.net>
	<1357143393-29832-2-git-send-email-benoit@irqsave.net>
	<50E5CB91.4040704@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <50E5CB91.4040704@redhat.com>
Subject: Re: [Qemu-devel] [RFC V4 01/30] qcow2: Add deduplication to the
 qcow2 specification.
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: Eric Blake <eblake@redhat.com>
Cc: kwolf@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com

> > +                                L2 tables size 64KB is different from
> > +                                cluster size 4KB.
> 
> Umm, doesn't the cluster_bits (bytes 20-23 of the header) determine the
> size of a cluster, rather than assuming a cluster is always 4KB?  And
> later on, the spec says that "L2 tables are exactly one cluster in
> size.", so I'm not sure what this comment is doing here.  Or are you
> stating that deduplication _also_ has an L2 table, which is fixed in
> size (unlike the normal L2 table for actual data)?

As most filesystems (ntfs, ext2/3/4, xfs) use 4KB blocs the deduplication
works very well with 4KB clusters.

The problem with 4KB cluster is that L2 table allocations are done very often
and require a flush to disk which kill performance.

So my patchset break compatibility with regular qcow2 image by using 64KB L2
table which are of a different size than the 4KB cluster.

I'll let the choice for the user to choose the cluster size but will default
to 4KB when creating a deduplicated image.