TRIM support for UFS?

[Christoph Hellwig]

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.