From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56115 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ou1k4-0007I9-Um for qemu-devel@nongnu.org; Fri, 10 Sep 2010 07:26:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ou1k3-0001hv-TE for qemu-devel@nongnu.org; Fri, 10 Sep 2010 07:26:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4202) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ou1k3-0001hl-J1 for qemu-devel@nongnu.org; Fri, 10 Sep 2010 07:26:03 -0400 Message-ID: <4C8A15C4.40201@redhat.com> Date: Fri, 10 Sep 2010 14:25:56 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format References: <1283767478-16740-1-git-send-email-stefanha@linux.vnet.ibm.com> <4C84E738.3020802@codemonkey.ws> <4C865187.6090508@redhat.com> <4C865CFE.7010508@codemonkey.ws> <4C8663C4.1090508@redhat.com> <4C866773.2030103@codemonkey.ws> <4C86BC6B.5010809@codemonkey.ws> <4C874812.9090807@redhat.com> <4C87860A.3060904@codemonkey.ws> <4C888287.8020209@redhat.com> <4C88D7CC.5000806@codemonkey.ws> <4C8A1311.8070903@redhat.com> In-Reply-To: <4C8A1311.8070903@redhat.com> 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: Anthony Liguori Cc: Kevin Wolf , Stefan Hajnoczi , qemu-devel@nongnu.org On 09/10/2010 02:14 PM, Avi Kivity wrote: > >> >> qcow2 is not a properly designed image format. It was a weekend >> hacking session from Fabrice that he dropped in the code base and >> never really finished doing what he originally intended. The >> improvements that have been made to it are almost at the heroic level >> but we're only hurting our users by not moving on to something better. >> > > I don't like qcow2 either. But from a performance perspective, it can > be made equivalent to qed with some effort. It is worthwhile to > expend that effort rather than push the burden to users. btw, despite being not properly designed, qcow2 is able to support TRIM. qed isn't able to, except by leaking clusters on shutdown. TRIM support is required unless you're okay with the image growing until it is no longer sparse (the lack of TRIM support in guests make sparse image formats somewhat of a joke, but nobody seems to notice). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.