This is an old thread, but just to make sure correct information is out there. TRIM or DISCARD (depending on whether you have a SATA or SCSI disk) is a hint to the storage device. It is used not just for SSD's, but also for Thin Provisioned volumes on enterprise storage arrays, such as those sold by EMC. (Linux has an implementation of this called dm-thin for local storage). There are multiple reasons why fstrim is the preferred mechanism for issuing trims. First, many SSD's and Thin Provisioning implementation can more efficiently process bulk trim commands. In particular, some storage arrays will ignore trims that are smaller than a megabyte, because the allocation granularity of the Thin Provisioning system is a megabyte, and some/many enterprise storage arrays don't track sub-allocation usage. Since the trim command is a hint, it is always legal to ignore a trim command, and so if you delete a large source tree, where none of the files are larger than a megabyte, depending on whether or how the OS batches the discard commands, the TRIM commands may have no effect if they are issued as the files are deleted.
Secondly, the trim command is a non-queueable command for most SATA SSD's (there are new SSD's that implement a new, queueable TRIM command, but they are rare, and while the Samsung EVO SSD's tried introducing the queuable trim via a firmware update, it was buggy, and had to be blacklisted and later withdrawn because it caused to file system and data corruption, and Samsung determined it could not be fixed via a firmware update). A non-queueable command means that the TRIM command has to wait for all other I/O requests to drain before it can be issued, and while it is being issued, no other I/O requests can be processed by the SSD. As such, issuing TRIM commands can interfere with more important I/O requests. (e.g., like those being issued by a database for a production workload.
For these two reasons, on Linux the recommended way to use TRIM is to use the fstrim command run out of cron, so that during an idle period the TRIM commands can be issued for all of the unused areas on the disk. Typically once a week is plenty; some people will go every night, or even once a month, since it is very workload dependent. This causes much less of a performance impact on production traffic, and for thin provisioning systems which use a large allocation granularity, it is much more effective. Note that this has nothing to do with a particular file system or OS implementation, but is much more about fundamental issues of how storage devices respond to TRIM commands, so what is best practice for Linux would also be a good thing to do on FreeBSD, if possible.
Note that one other scenario when fstrim is useful is before creating a snapshot or image on a cloud system, such as Google Compute Engine. The TRIM command tells the VM's storage subsystem which blocks are in use, and which are not in use. This allows the resulting snapshot and image to (a) be created more quickly, and (b) be cheaper since for snapshots and images, you are charged only for the blocks which are in use, and not the size of the source disk from which the snapshot or image was created. (Indeed, this is how I came across this thread; I was assisting the e2fsprogs Ports maintainer on fixing some portability problems with e2fsprogs that came up with FreeBSD-11, and in order to do that I had to create some FreeBSD 11-rc2 GCE VM instances, and while trying to create backup snapshots of my FreeBSD-10 and FreeBSD-11 VM's, I tried to determine if there was a fstrim-equivalent for FreeBSD, since the GCE VM images published by the FreeBSD organization don't enable TRIM by default on the file system, and I like to optimize any snapshots or images I create.)
Best regards,
Ted
P.S. Ext4's discard feature can be useful, but only in very highly specialized use cases. For example, if you have a PCI-e attached flash device where the FTL is implemented as a host OS driver, sending discards as soon as the file is deleted is useful since it is fast (the FTL is running on the host, and it isn't subject to the limitations of the SATA command), and it can reduce the FTL's GC overhead, both in terms of reducing flash writes and CPU and memory overhead of the FTL on the host. However, aside from these specific instances, sending bulk trims of unused space, triggered out of cron once a week or so, is what I generally recommend as best practice for most systems.
P.P.S. In Linux the fstrim functionality is implemented in the kernel, and is supported by most of the major file systems (including ext4, btrfs, and xfs). This means that even though fstrim is triggered from userspace, typically via a sysadmin command or out of cron, it is safe to run on a mounted file system, since the kernel locks out allocations from the block/allocation/cylinder group while the TRIM commands are in flight for that particular part of the disk. It would be nice if FreeBSD had a similar feature since it is helpful for use cases beyond SSD's, including on guest VM's.
