Date: Fri, 10 Dec 2010 03:36:13 -0500 From: Christoph Hellwig <hch@infradead.org> To: Julian Elischer <julian@freebsd.org> Cc: Kirk McKusick <mckusick@mckusick.com>, Oliver Fromme <olli@lurza.secnetix.de>, Pawel Jakub Dawidek <pjd@freebsd.org>, freebsd-fs@freebsd.org Subject: Re: TRIM support for UFS? Message-ID: <20101210083613.GA12835@infradead.org> In-Reply-To: <4D01B878.4020008@freebsd.org> References: <201012091813.oB9IDd2H078366@chez.mckusick.com> <20101210003749.3F7E15B92@mail.bitblocks.com> <20101210005838.GD1866@garage.freebsd.pl> <4D01B878.4020008@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101210083613.GA12835>