From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37650 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OtaiM-0004Lk-BO for qemu-devel@nongnu.org; Thu, 09 Sep 2010 02:34:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OtaYs-0002id-23 for qemu-devel@nongnu.org; Thu, 09 Sep 2010 02:24:43 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23467) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OtaYr-0002iJ-OU for qemu-devel@nongnu.org; Thu, 09 Sep 2010 02:24:42 -0400 Message-ID: <4C887D9A.3020702@redhat.com> Date: Thu, 09 Sep 2010 09:24:26 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format References: <4C866773.2030103@codemonkey.ws> <4C86BC6B.5010809@codemonkey.ws> <4C874812.9090807@redhat.com> <395D4377-00F9-4765-94C4-470BDFA1F96E@suse.de> <4C874F22.6060802@redhat.com> <20100908153857.GA30438@lst.de> <4C87BA12.5040909@codemonkey.ws> <20100908202336.GA7855@lst.de> <4C87F202.5000602@codemonkey.ws> <20100909023550.GA19336@lst.de> In-Reply-To: <20100909023550.GA19336@lst.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoph Hellwig Cc: Kevin Wolf , Stefan Hajnoczi , Stefan Hajnoczi , Alexander Graf , qemu-devel@nongnu.org On 09/09/2010 05:35 AM, Christoph Hellwig wrote: > 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. That only works if the initial write writes the entire extent (zero-filling a shorter write). But that both slows down that write, and quickly grows the image to its full logical size. The other thing we can do is defragment the logical image, then defragment the underlying file (if the filesystem supports it, issue the appropriate ioctl, otherwise defragment to a new file which you write linearly). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.