Solved SSD Trim Maintenance

Not sure if this is the right area but seems appropriate. Using FreeBSD 10.3 as a desktop and have trim support enabled on the SSD drives I use. The drives fully support trim. Do I need to periodically run something like fstrim -v / as I would have on Linux? I ran this command on my Linux box roughly weekly. Thanks in advance.
 
Thanks for the reply - from reading both articles/posts, it appears that since I have enabled trim on both SSDs I am using, that is all that is needed and I need not do anything more. At least that's what I took from the articles. Thanks!
 
You don't need to actively do anything. The disks' firmware handles everything once the OS/filesystem notifies it that blocks are freed. The -E flag can also be used with newfs when formatting a partition to erase all blocks; it shouldn't be necessary, but it's handy if you want to be sure you have a clean disk to start with.
 
The Linux command has a bulk trim function, but that is the same one where they had problems with certain SSDs. As above, it should not be necessary when blocks are released individually by the filesystem. The SSD will also do wear leveling in the background.
 
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.
 
There are at least two more ways to issue the TRIM/DISCARD command. These are through newfs -E and fsck_ffs -E. On newfs, it will delete all blocks before creating the file system. With fsck_ffs it's almost what we would want here. The only downside is that you have to go through an fsck. It works on mounted file systems too. You can see which blocks are deleted using fsck_ffs -dE (where -d activates debug output).

These options appear in the release notes for RELEASE-8.3, https://www.freebsd.org/releases/8.3R/relnotes-detailed.html . To make Ted's post more clear, with the mount option, you pay a penalty on each file delete, and you can trade that for a couple of seconds each week or each month.

It's not as fast as fstrim on ext4fs though...
 
10.3-RELEASE amd64.
Esata SSD octane 2, disk size 64g, one gpt partition 40g.
Code:
# fsck_ffs -E /dev/gpt/octane

This seems to wipe the gpt secondary header at the last LBA.

Code:
# dmesg

ada1 at ahcich4 bus 0 scbus3 target 0 lun 0
ada1: <OCZ-OCTANE S2 4.13> ATA8-ACS SATA 2.x device
ada1: Serial Number OCZ-A5R76E1DAJN7H79X
ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 61057MB (125045424 512 byte sectors)
ada1: Previously was known as ad10
GEOM: ada1: the secondary GPT header is not in the last LBA.
GEOM: diskid/DISK-OCZ-A5R76E1DAJN7H79X: the secondary GPT header is not in the last LBA.

No big deal but was surprised it affected an area outside partition one.
Easy to restore.
Code:
#gpart recover /dev/gpt/octane
 
Are you sure? That is very unlikely. That means fsck doing a mistake, and then the geom slice allowing the delete many GBs past the end of the slice. Maybe a bug on your SSD? If you really can reproduce that, you should post that elsewhere. Also, it would be interesting if you can reproduce it on a different disk.
 
Thanks for your reply.
I can NOT reproduce this when connected via esata.
Must have used fsck_ffs -E when connected via USB.
I wanted to use this external drive with both esata and usb.
Having multiple issues when using this drive with USB.
Will use esata only from now on.
My apologies for jumping the gun.
 
Back
Top