From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=46795 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Ou4LP-0006us-Vg
	for qemu-devel@nongnu.org; Fri, 10 Sep 2010 10:12:49 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <hch@lst.de>) id 1Ou4LO-0003MK-KC
	for qemu-devel@nongnu.org; Fri, 10 Sep 2010 10:12:47 -0400
Received: from verein.lst.de ([213.95.11.210]:46075)
	by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from <hch@lst.de>)
	id 1Ou4LO-0003M0-Av
	for qemu-devel@nongnu.org; Fri, 10 Sep 2010 10:12:46 -0400
Date: Fri, 10 Sep 2010 16:12:42 +0200
From: Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format
Message-ID: <20100910141242.GA30542@lst.de>
References: <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>
	<AANLkTi=tt+Zh_i15LFz36kOdD8sFBKpJ2wsPRGM=3zkV@mail.gmail.com>
	<20100910134701.GA28831@lst.de> <4C8A3B1C.4040807@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4C8A3B1C.4040807@redhat.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Avi Kivity <avi@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Stefan Hajnoczi <stefanha@gmail.com>, qemu-devel@nongnu.org, Christoph Hellwig <hch@lst.de>, Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>

On Fri, Sep 10, 2010 at 05:05:16PM +0300, Avi Kivity wrote:
> >Note that ATA allows simply ignoring TRIM requests that we can't handle,
> >and if we don't set the bit that guarantees TRIMed regions to be zeroed
> >we don't even have to zero out the regions.
> 
> It would be nice to support it.  TRIM is important to recover space, 
> otherwise images grow and grow and there's no point in using a sparse 
> format in the first place.

Sure.  But supporting to tiny TRIM requests doesn't make sense.  That
is the same behaviour we see from real life SSDs, btw.  If the request
is smaller than their erase block size or whatever internal structure
they use to track allocations it will not actually free space.  On some
of the lesser quality consumer SSDs the sectors won't even be zeroed
even if they claim so in the ATA IDENTIFY response.