From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50247) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tbtwe-0004qI-9O for qemu-devel@nongnu.org; Fri, 23 Nov 2012 09:09:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TbtwU-000264-Q8 for qemu-devel@nongnu.org; Fri, 23 Nov 2012 09:09:28 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36046) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbtwU-00025H-IE for qemu-devel@nongnu.org; Fri, 23 Nov 2012 09:09:18 -0500 Message-ID: <50AF838B.5010703@redhat.com> Date: Fri, 23 Nov 2012 15:09:15 +0100 From: Kevin Wolf MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] qcow2: slow internal snapshot creation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexandre DERUMIER Cc: Dietmar Maurer , qemu-devel@nongnu.org Am 23.11.2012 15:03, schrieb Alexandre DERUMIER: > performance is also reduced when snapshot exist. (like if they are no preallocated metadatas) Preallocation doesn't matter much these days. > see initial git commit > > http://git.qemu.org/?p=qemu.git;a=commit;h=a35e1c177debb01240243bd656caca302410d38c > "qcow2: Metadata preallocation > > This introduces a qemu-img create option for qcow2 which allows the metadata 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 during > 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 cheat > 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