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. The TRIM command tells the VM's storage subsystem which blocks are in use, and which are not in use. 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. 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. 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. Typically once a week is plenty some people will go every night, or even once a month, since it is very workload dependent. (e.g., like those being issued by a database for a production workload.įor 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. As such, issuing TRIM commands can interfere with more important I/O requests. 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. 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). 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. 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. First, many SSD's and Thin Provisioning implementation can more efficiently process bulk trim commands. There are multiple reasons why fstrim is the preferred mechanism for issuing trims. (Linux has an implementation of this called dm-thin for local storage). It is used not just for SSD's, but also for Thin Provisioned volumes on enterprise storage arrays, such as those sold by EMC. TRIM or DISCARD (depending on whether you have a SATA or SCSI disk) is a hint to the storage device. This is an old thread, but just to make sure correct information is out there.