From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=45143 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ou20l-0005hB-Aj for qemu-devel@nongnu.org; Fri, 10 Sep 2010 07:43:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ou20k-0004Ul-1R for qemu-devel@nongnu.org; Fri, 10 Sep 2010 07:43:19 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52201) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ou20j-0004UZ-QF for qemu-devel@nongnu.org; Fri, 10 Sep 2010 07:43:17 -0400 Message-ID: <4C8A19CA.3040000@redhat.com> Date: Fri, 10 Sep 2010 14:43:06 +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> <4C8A15C4.40201@redhat.com> In-Reply-To: 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: Stefan Hajnoczi Cc: Kevin Wolf , Stefan Hajnoczi , qemu-devel@nongnu.org On 09/10/2010 02:33 PM, Stefan Hajnoczi wrote: > >> 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). > Anthony has started writing up notes on trim for qed: > http://wiki.qemu.org/Features/QED/Trim > Looks like it depends on fsck, which is not a good idea for large images. > 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. To deal with a sub-cluster TRIM, look at the surrounding sectors. If they're zero, free the cluster. If not, write zeros or use sys_punch() to the range specified by TRIM. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.