From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LLDIC-00029d-Ot
	for qemu-devel@nongnu.org; Fri, 09 Jan 2009 04:04:36 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LLDIA-00028W-QA
	for qemu-devel@nongnu.org; Fri, 09 Jan 2009 04:04:36 -0500
Received: from [199.232.76.173] (port=55616 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LLDIA-00028P-IC
	for qemu-devel@nongnu.org; Fri, 09 Jan 2009 04:04:34 -0500
Received: from mx2.suse.de ([195.135.220.15]:36623)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <kwolf@suse.de>) id 1LLDIA-0003GE-0q
	for qemu-devel@nongnu.org; Fri, 09 Jan 2009 04:04:34 -0500
Message-ID: <49671463.8050402@suse.de>
Date: Fri, 09 Jan 2009 10:09:55 +0100
From: Kevin Wolf <kwolf@suse.de>
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>
In-Reply-To: <49664ACA.9050807@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
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: qemu-devel@nongnu.org
Cc: Uri Lublin <uril@redhat.com>

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.

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.

Kevin