From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=51182 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OtWzW-00083j-SE
	for qemu-devel@nongnu.org; Wed, 08 Sep 2010 22:36:00 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <hch@lst.de>) id 1OtWzU-0006rg-QJ
	for qemu-devel@nongnu.org; Wed, 08 Sep 2010 22:35:58 -0400
Received: from verein.lst.de ([213.95.11.210]:51290)
	by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from <hch@lst.de>)
	id 1OtWzU-0006rM-IB
	for qemu-devel@nongnu.org; Wed, 08 Sep 2010 22:35:56 -0400
Date: Thu, 9 Sep 2010 04:35:50 +0200
From: Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format
Message-ID: <20100909023550.GA19336@lst.de>
References: <4C866773.2030103@codemonkey.ws> <4C86BC6B.5010809@codemonkey.ws>
	<4C874812.9090807@redhat.com>
	<395D4377-00F9-4765-94C4-470BDFA1F96E@suse.de>
	<4C874F22.6060802@redhat.com>
	<AANLkTik+NHXjVmW5ozSGOOLf_FeQE8DHhoQPN6LOpFW0@mail.gmail.com>
	<20100908153857.GA30438@lst.de>
	<4C87BA12.5040909@codemonkey.ws> <20100908202336.GA7855@lst.de>
	<4C87F202.5000602@codemonkey.ws>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4C87F202.5000602@codemonkey.ws>
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.nongnu.org/archive/html/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: Anthony Liguori <anthony@codemonkey.ws>
Cc: Kevin Wolf <kwolf@redhat.com>, Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>, Stefan Hajnoczi <stefanha@gmail.com>, qemu-devel@nongnu.org, Alexander Graf <agraf@suse.de>, Avi Kivity <avi@redhat.com>, Christoph Hellwig <hch@lst.de>

On Wed, Sep 08, 2010 at 03:28:50PM -0500, Anthony Liguori wrote:
> That's a good point.  Is there a reasonable way to do this cooperatively 
> with the underlying filesystem?

The only thing we can do easily is to try to use as large as possible
extents in the allocation.  Once we're at a cuple Megabytes the
fragmentation doesn't matter too much.

> BTW, the same problem would occur for sparse file system images, no?

Sparse filesystems images are relatively probe to fragmentation, too.
Some filesystems like ext4 have heuristics that try to related physical
locality to logical locality, but that only helps if the filesystem is
relatively empty.  On XFS you can set a minimum extent size which forces
the filesystem to allocate more data than nessecary and thus reduce
fragmentation.  That's equivalent to suggestion a above to use larger
extents in the image format.