From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LLwfm-0001Ej-6g
	for qemu-devel@nongnu.org; Sun, 11 Jan 2009 04:31:58 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LLwfl-0001Dc-0g
	for qemu-devel@nongnu.org; Sun, 11 Jan 2009 04:31:57 -0500
Received: from [199.232.76.173] (port=56895 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LLwfk-0001DN-NH
	for qemu-devel@nongnu.org; Sun, 11 Jan 2009 04:31:56 -0500
Received: from mx2.redhat.com ([66.187.237.31]:42632)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <uril@redhat.com>) id 1LLwfk-0001Ql-9n
	for qemu-devel@nongnu.org; Sun, 11 Jan 2009 04:31:56 -0500
Message-ID: <4969BC89.9040405@redhat.com>
Date: Sun, 11 Jan 2009 11:31:53 +0200
From: Uri Lublin <uril@redhat.com>
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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Kevin Wolf <kwolf@suse.de>
Cc: qemu-devel@nongnu.org

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.

I don't know, it has to be implemented and measured.

> 
> 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.

That should make qcow2 images less defragmented.

Thanks,
     Uri.