With many Mac users switching from hard disk storage to SSDs, and following my recent article about adding a two-SSD external enclosure, I thought it might be useful to look at some commonly-raised issues about SSDs: TRIM, wear levelling, and how they interact (or don’t) with macOS, particularly APFS.

TRIM

This isn’t an abbreviation, but refers to the TRIM command, which is central to this issue.

On any storage medium, the file system normally deletes files by marking their storage blocks as being no longer in use. When re-using those blocks for new files only requires that they are rewritten, as on a hard disk, that’s not a problem, as the disk controller can choose to reuse them whenever it wants without any side effects.

However, before NAND flash memory cells used in SSDs can be re-used for writing, their contents must be erased, a process which makes writing to them significantly slower. This is complicated by the fact that data is written in pages of 4-16 kB, but erase commands always affect complete blocks, which typically consist of 128-512 pages. This is commonly addressed by relocating any other retained data within the block, so enabling that block to be erased ready to receive the new data.

To avoid incurring such overhead, the operating system can maintain a list of blocks which are no longer in use, and once a block becomes unused, it can inform the SSD’s firmware that the block can now be re-used. This allows the SSD controller to erase that block, and maintains good write performance even under heavy use with limited free space. That’s what the TRIM command does.

Operating systems, including macOS, gained TRIM support around 2010, but this has proved quite complex and varied by type of SSD, and by file system. While generally available for software RAID systems, except AppleRAID, the TRIM command is normally not supported by hardware RAID systems.

Enabling TRIM doesn’t automatically improve performance, and in some circumstances can instead impair performance. In early releases of APFS, users who manually enabled TRIM sometimes encountered longer boot times, which have been attributed to TRIM commands being sent to the SSD during the boot process.

In practice, it shouldn’t be hard to detect poor write performance on an SSD which could be addressed by enabling TRIM. I have yet to see any reports that external SSDs in APFS format need TRIM to be enabled because write performance has deteriorated, although the default in macOS appears to be to disable TRIM support for external SSDs.

Most accounts of TRIM and its support are now getting quite old, and don’t refer to file systems such as APFS which are optimised to work with SSDs. I’ve been unable to find any recent recommendation from Apple or a similarly authoritative source that TRIM support should be enabled on internal or external SSDs running the current version of APFS.

For the moment, in the absence of any better information, I suggest that it’s wise to buy external enclosures and drives which can support TRIM, but not to enable it unless you observe slowed write performance on your SSD. The command that you’ll then need to use is
trimforce enable
followed by restarting your Mac for it to take effect. It applies to all mounted external SSDs. The man page warns: “Use extreme caution when enabling TRIM, as some drives may not correctly handle the commands.”

As far as I can see at present, looking in System Information and Disk Utility, you can only tell whether TRIM is enabled on certain SSDs, including those mounted internally or connected via buses such as Thunderbolt 3 which seem to pass this information. This is given in System Information when you select that SSD according to its connection. But no information on TRIM support is given for the most common connection for external SSDs, USB 3.1. The trimforce command doesn’t have a verb which will inform you either.

Wear levelling

Whilst TRIM centres on write performance of an SSD, wear levelling is all about preventing an SSD from wearing out prematurely.

Each erasable block in an SSD has a finite number of erase cycles before it becomes unreliable. Figures quoted for that number range between 3,000-5,000, and may exceed that in modern higher-quality SSDs. If the SSD were to be used in a way that a few blocks were erased very frequently, those would hit their limit long before the rest of the blocks, and could result in the SSD failing much earlier than if the erase cycles were more evenly distributed across all the blocks in the SSD.

Wear levelling is normally performed by the SSD’s inbuilt controller, and isn’t controlled in any way by the file system or operating system. However, the way that the file system handles its own metadata and file writes can significantly influence the work required by the SSD to keep wear levelled across its blocks.

File systems designed for general use, or in the days when almost all writable storage was on magnetic media, usually don’t behave in a way that aids wear levelling. APFS has a feature which should improve wear levelling, though: copy on write.

Automatic wear levelling systems are most challenged when a file system always tries to write changed data to the same blocks as the originals, as some files and data (especially metadata) are very active and change frequently, and others are static over long periods. In contrast, APFS writes changed data to a different block, and then marks the old block as no longer being in use. This doesn’t change the total number of erase cycles, but enables them to be spread more evenly over the SSD even when only a few files are very active.

Automatic wear levelling should be a feature of all modern SSDs, although their specifications often take this for granted, and don’t mention it.

Fragmentation

If you operated hard disks over years, you’ll be only too aware of the problems of fragmentation on them, both of stored data and of free space. Many of us ran utilities which aimed to move data around on a hard drive to reduce its fragmentation, and concentrate disk free space in large contiguous areas of the disk.

Most of the problems which fragmentation causes result from the fact that hard disks have to seek each fragment to read a whole file, and that seek time slows file access significantly. However, because SSDs work without any such seeking, fragmentation doesn’t cause such problems. Not only that, but relocating the data to assemble files in contiguous storage would involve multiple writes including erasure, which would accelerate the ageing of an SSD.

In practice, therefore, fragmentation can largely be ignored on SSDs. Running APFS on a hard drive is another matter altogether, of course, and one criticism of the new file system is that it still doesn’t perform too well on hard disks.

APFS

Apple has still released very limited information about APFS, and its latest reference manual doesn’t mention TRIM at all, for instance. Two important sub-systems within APFS are its Space Manager (‘Spaceman’) and the Reaper.

Spaceman is responsible for allocating and freeing blocks to store file system objects and file data. Each APFS container has just one Spaceman, which has to manage all space within that container, for as many volumes as share that space. The Reaper is the mechanism by which APFS deletes large objects, which require multiple transactions within the file system. Again, there is only one Reaper for each APFS container. It’s the Reaper which is responsible for cleaning up deleted snapshots, for example.

In summary:

• TRIM may be important for addressing poor write performance in certain circumstances, but isn’t well supported in macOS and is normally turned off. We need better information from Apple as to whether it should ever be enabled on APFS external drives.
• Wear levelling should be built into every modern SSD, and APFS works in its favour.
• Forget defragmentation on SSDs, it’s no longer an issue.
• APFS has sophisticated features which manage SSDs more effectively, but are currently almost undocumented.

References

Wikipedia on TRIM
Wikipedia on wear levelling.

Amended thanks to helpful comment from Gerald P – see below.