From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36639) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKqGE-0005nk-BL for qemu-devel@nongnu.org; Wed, 27 Mar 2013 09:19:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKqGC-00077J-HC for qemu-devel@nongnu.org; Wed, 27 Mar 2013 09:19:26 -0400 Received: from nodalink.pck.nerim.net ([62.212.105.220]:36541 helo=paradis.irqsave.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKqG8-000739-KP for qemu-devel@nongnu.org; Wed, 27 Mar 2013 09:19:24 -0400 Date: Wed, 27 Mar 2013 14:20:18 +0100 From: =?iso-8859-1?Q?Beno=EEt?= Canet Message-ID: <20130327132018.GA4095@irqsave.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] QCOW2 deduplication key value store List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Kevin Wolf , Stefan Hajnoczi Hello, I am starting this thread so we can discuss of the choice of a good key/v= alue store for the QCOW2 deduplication. One of the main goal is to keep the ratio between the number of cluster w= ritten and the number of dedup metadata io high. I initially though about taking the first two stages of SILT (http://goo.gl/x7UcI) to build the key value store. The very nice thing about the two first stage of SILT is that the write i= o involved are not random at all: The log is obviously not random and the conversion into the second stage hash table can be done sequentially. This makes the io ratio very high. Kevin later thought about combining the first stage of SILT with a big ha= sh table as a second stage. While this method is simpler I don't understand how we can inject the fir= st stage into this big table without generating a log of random ios. Best regards Beno=EEt