From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LM1jl-0007yi-46 for qemu-devel@nongnu.org; Sun, 11 Jan 2009 09:56:25 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LM1ji-0007xg-Qv for qemu-devel@nongnu.org; Sun, 11 Jan 2009 09:56:23 -0500 Received: from [199.232.76.173] (port=51570 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LM1ji-0007xd-LQ for qemu-devel@nongnu.org; Sun, 11 Jan 2009 09:56:22 -0500 Received: from mx2.redhat.com ([66.187.237.31]:44253) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LM1ji-0001nk-2G for qemu-devel@nongnu.org; Sun, 11 Jan 2009 09:56:22 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n0BEuKMV013992 for ; Sun, 11 Jan 2009 09:56:20 -0500 Message-ID: <496A0899.7010707@redhat.com> Date: Sun, 11 Jan 2009 16:56:25 +0200 From: Shahar Frank MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/3] info blockstats (block-qcow2): show highest allocated offset (bytes) References: <49664ACA.9050807@redhat.com> <49671463.8050402@suse.de> In-Reply-To: <49671463.8050402@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Uri Lublin Kevin Wolf wrote: > Uri Lublin schrieb: >> Although there may be many free blocks below that number (allocated and >> freed) >> the file system can not deallocate those blocks, and they have to be reused >> by qemu. Also note that due to fragmentation those free blocks may not >> be used on next allocations. > > Any idea what would it mean to performance if we changed the behaviour > so that s->free_cluster_index always points to lowest free cluster? Then > most of the fragmentation should be gone. > free_cluster_index if already pointing the lowest known free space. The problem is that the its update logic is very simplistic so an allocation of multiple clusters may cause this pointer to skip many single (in fact it will skip all cluster sequences that are shorter than the requested number), so the next allocation may miss it. This will increase the fragmentation. Note that it wasn't so important until Laurent Vivier implemented his optimizations that allocated cluster sequences. see block-qcow2.c:alloc_clusters_noref() and block-qcow2.c: update_cluster_refcount() > If the impact would be too big we could still change the code to use two > free_cluster_indexes, one for single cluster allocation and one for > larger blocks. This was suggested earlier and I think there were even > patches for it, but I don't seem to remember who exactly suggested this. > I suggested it as part of the first zero-dedup patch, and that was because I suspected that the zero dedup may increase fragmentation due that simplistic free cluster indexes. In fact, having two or even several free pointers is probably a step in the right direction, but we may need some better allocation mechanism to really solve the problem (btree+ structure, or something else). The target should be a decent extend based allocation. This improve qcow2 performance and handle he fragmentation problem. The problem is that it will probably change the qcow2 internals, so may better implement a simple approach for qcow2 and start designing qcow3... > Kevin > > Shahar