From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=51615 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OtRGL-0008ED-UE for qemu-devel@nongnu.org; Wed, 08 Sep 2010 16:28:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OtRGK-0005ox-FU for qemu-devel@nongnu.org; Wed, 08 Sep 2010 16:28:57 -0400 Received: from mail-yx0-f173.google.com ([209.85.213.173]:50973) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OtRGK-0005os-C0 for qemu-devel@nongnu.org; Wed, 08 Sep 2010 16:28:56 -0400 Received: by yxs7 with SMTP id 7so309924yxs.4 for ; Wed, 08 Sep 2010 13:28:55 -0700 (PDT) Message-ID: <4C87F202.5000602@codemonkey.ws> Date: Wed, 08 Sep 2010 15:28:50 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format References: <4C865CFE.7010508@codemonkey.ws> <4C8663C4.1090508@redhat.com> <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> In-Reply-To: <20100908202336.GA7855@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 , qemu-devel@nongnu.org, Alexander Graf , Avi Kivity On 09/08/2010 03:23 PM, Christoph Hellwig wrote: > On Wed, Sep 08, 2010 at 11:30:10AM -0500, Anthony Liguori wrote: > >> http://wiki.qemu.org/Features/QED/OnlineDefrag >> >> Is a spec for a very simple approach to online defrag that I hope we can >> implement in the near future. I think that once we have the mechanisms >> to freeze clusters and to swap clusters, implementing much more >> sophisticated defragmentation algorithms will become easy. >> > This image defragmentation might in fact cause even more fragmentation > at the filesystem layer. > That's a good point. Is there a reasonable way to do this cooperatively with the underlying filesystem? BTW, the same problem would occur for sparse file system images, no? Regards, Anthony Liguori