From owner-freebsd-fs@FreeBSD.ORG Fri Dec 10 08:36:38 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EB1B106564A; Fri, 10 Dec 2010 08:36:38 +0000 (UTC) (envelope-from BATV+870d71e9bf4a5d360c11+2665+infradead.org+hch@bombadil.srs.infradead.org) Received: from bombadil.infradead.org (unknown [IPv6:2001:4830:2446:ff00:4687:fcff:fea6:5117]) by mx1.freebsd.org (Postfix) with ESMTP id E1A478FC15; Fri, 10 Dec 2010 08:36:37 +0000 (UTC) Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PQySb-0004vO-Cc; Fri, 10 Dec 2010 08:36:13 +0000 Date: Fri, 10 Dec 2010 03:36:13 -0500 From: Christoph Hellwig To: Julian Elischer Message-ID: <20101210083613.GA12835@infradead.org> References: <201012091813.oB9IDd2H078366@chez.mckusick.com> <20101210003749.3F7E15B92@mail.bitblocks.com> <20101210005838.GD1866@garage.freebsd.pl> <4D01B878.4020008@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D01B878.4020008@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html Cc: Kirk McKusick , Oliver Fromme , Pawel Jakub Dawidek , freebsd-fs@freebsd.org Subject: Re: TRIM support for UFS? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 08:36:38 -0000 On Thu, Dec 09, 2010 at 09:19:52PM -0800, Julian Elischer wrote: > One of the things that has not been mentioned is that trim is not > really 'free' > (at least not for us) if you want things to remain trimmed after a reboot. > so if I were implementing it I'd want a couple of parameters. > > 1/ don't bother trimming free space under some size. > 2/ does it matter if the trimmed space comes back as garbage > after an unclean shutdown? (a hint to the driver, and no, I don't > know anyone that supports this yet) > (there are security implications to that one but cheap trim (that > may come back) is way cheaper than persistent trim to impliment). Please take a look at the SCSI and ATA standards for thin provisioning and TRIM. For SCSI there are EVPD pages with a lot of information about the required trim granularity and alignment. For SCSI an UNMAP or WRITE SAME with the unmap bit set always guarantees deterministic behaviour after a discard of used data, which is optional in ATA, but all SSDs I have access to claim to support it (but at least one didn't do it properly). Both SBC and ATA have a bit that requires any discarded space to be zeroed, which is very important for RAID or virtualization use cases. I would suggest to let the BSD implementation mirror those standards - that's what we've done for Linux. Another interesting angle is that the SCSI UNAMP command and the ATA TRIM command support ranges of blocks to discard, which is a feature that Windows 7 uses a lot on SSDs, given that the overhead of a single TRIM can be quite bad given that it's a non-queueable command. If you want to add ioctls for trimming on raw block devices, the free space on a filesystem, or punching holes please take a look at the existing Linux BLKDISCARD and FITRIM ioctls, as well as the fallocate extension to punch holes that's currently under discussion.