From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=49794 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ou1qx-0001gY-Si for qemu-devel@nongnu.org; Fri, 10 Sep 2010 07:33:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ou1qw-0002if-QG for qemu-devel@nongnu.org; Fri, 10 Sep 2010 07:33:11 -0400 Received: from mail-vw0-f45.google.com ([209.85.212.45]:56458) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ou1qw-0002ia-Kr for qemu-devel@nongnu.org; Fri, 10 Sep 2010 07:33:10 -0400 Received: by vws19 with SMTP id 19so2508276vws.4 for ; Fri, 10 Sep 2010 04:33:10 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4C8A15C4.40201@redhat.com> 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> <4C8A15C4.40201@redhat.com> Date: Fri, 10 Sep 2010 12:33:09 +0100 Message-ID: Subject: Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Kevin Wolf , Stefan Hajnoczi , qemu-devel@nongnu.org On Fri, Sep 10, 2010 at 12:25 PM, Avi Kivity wrote: > =A0On 09/10/2010 02:14 PM, Avi Kivity wrote: >> >>> >>> qcow2 is not a properly designed image format. =A0It was a weekend hack= ing >>> session from Fabrice that he dropped in the code base and never really >>> finished doing what he originally intended. =A0The improvements that ha= ve been >>> made to it are almost at the heroic level but we're only hurting our us= ers >>> by not moving on to something better. >>> >> >> I don't like qcow2 either. =A0But from a performance perspective, it can= be >> made equivalent to qed with some effort. =A0It is worthwhile to expend t= hat >> effort rather than push the burden to users. > > btw, despite being not properly designed, qcow2 is able to support TRIM. > =A0qed isn't able to, except by leaking clusters on shutdown. =A0TRIM sup= port 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). Anthony has started writing up notes on trim for qed: http://wiki.qemu.org/Features/QED/Trim I need to look at the actual ATA and SCSI specs for how this will work. The issue I am concerned with is sub-cluster trim operations. If the trim region is less than a cluster, then both qed and qcow2 don't really have a way to handle it. Perhaps we could punch a hole in the file, given a userspace interface to do this, but that isn't ideal because we're losing sparseness again. Stefan