From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:45508)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benoit.canet@irqsave.net>) id 1UuMBT-0007TO-4T
	for qemu-devel@nongnu.org; Wed, 03 Jul 2013 08:29:20 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <benoit.canet@irqsave.net>) id 1UuMBP-0003oY-S6
	for qemu-devel@nongnu.org; Wed, 03 Jul 2013 08:29:19 -0400
Received: from nodalink.pck.nerim.net ([62.212.105.220]:39013
	helo=paradis.irqsave.net) by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <benoit.canet@irqsave.net>) id 1UuMBP-0003oH-G8
	for qemu-devel@nongnu.org; Wed, 03 Jul 2013 08:29:15 -0400
Date: Wed, 3 Jul 2013 14:30:59 +0200
From: =?iso-8859-1?Q?Beno=EEt?= Canet <benoit.canet@irqsave.net>
Message-ID: <20130703123059.GA5482@irqsave.net>
References: <1371738392-9594-1-git-send-email-benoit@irqsave.net>
	<1371738392-9594-2-git-send-email-benoit@irqsave.net>
	<20130702144224.GF9870@stefanha-thinkpad.redhat.com>
	<20130702212355.GB4985@irqsave.net>
	<20130703080415.GA2784@dhcp-200-207.str.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <20130703080415.GA2784@dhcp-200-207.str.redhat.com>
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [RFC V8 01/24] qcow2: Add journal 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: Kevin Wolf <kwolf@redhat.com>
Cc: =?iso-8859-1?Q?Beno=EEt?= Canet <benoit.canet@irqsave.net>, qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>

> Care to explain that in more detail? Why shouldn't it work on spinning
> disks?

Hash are random they introduce random read access.

With a QCOW2 cluster size of 4KB the deduplication code when writting dup=
licated
data will do one random read per 4KB block to deduplicate.

A server grade hardisk is rated for 250 iops. This traduce in 1MB/s of de=
duplicated
data. Not very usable.

On the contrary a samsung 840 pro SSD is rated for 80k iops of random rea=
d.
That should traduce in 320MB/s of potentially deduplicated data.

Havind dedup metadata on SSD and actual data on disk would solve the prob=
lem but
it would need block backend.

Beno=EEt