From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57318) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tbu4d-0001R8-89 for qemu-devel@nongnu.org; Fri, 23 Nov 2012 09:17:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tbu4V-0004SI-Db for qemu-devel@nongnu.org; Fri, 23 Nov 2012 09:17:43 -0500 Received: from mailpro.odiso.net ([89.248.209.98]:34123) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tbu4V-0004SD-7I for qemu-devel@nongnu.org; Fri, 23 Nov 2012 09:17:35 -0500 Date: Fri, 23 Nov 2012 15:17:04 +0100 (CET) From: Alexandre DERUMIER Message-ID: <9574d6cc-30fe-4424-b7e7-d363e2abdba9@mailpro> In-Reply-To: <50AF838B.5010703@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Qemu-devel] qcow2: slow internal snapshot creation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Dietmar Maurer , qemu-devel@nongnu.org >>Preallocation doesn't matter much these days. I have done benchmark through nfs on a netapp san, (with directio), I got 300 iops without preallocation, and 6000 iops with preallocation ....= ----- Mail original ----- De: "Kevin Wolf" =C3=80: "Alexandre DERUMIER" Cc: "Dietmar Maurer" , qemu-devel@nongnu.org Envoy=C3=A9: Vendredi 23 Novembre 2012 15:09:15 Objet: Re: [Qemu-devel] qcow2: slow internal snapshot creation Am 23.11.2012 15:03, schrieb Alexandre DERUMIER: > performance is also reduced when snapshot exist. (like if they are no pre= allocated metadatas) Preallocation doesn't matter much these days. > see initial git commit > > http://git.qemu.org/?p=3Dqemu.git;a=3Dcommit;h=3Da35e1c177debb01240243bd6= 56caca302410d38c > "qcow2: Metadata preallocation > > This introduces a qemu-img create option for qcow2 which allows the metad= ata to > be preallocated, i.e. clusters are reserved in the refcount table and L1/= L2 > tables, but no data is written to them. Metadata is quite small, so this = > happens in almost no time. > > Especially with qcow2 on virtio this helps to gain a bit of performance d= uring > the initial writes. However, as soon as create a snapshot, we're back to = the > normal slow speed, obviously. So this isn't the real fix, but kind of a c= heat > while we're still having trouble with qcow2 on virtio." This is a commit message from 2009 that already says that this wasn't the final solution. Kevin