Mac OS X 10.10.4 Supports TRIM for Third-Party SSD Hard Drives

Someone over at Ars Technica posted a warning about using TRIM with certain hard drives. I'll quote it here:

HEED THE DATA LOSS WARNING!

There are a number of extremely buggy SSD models out there (like almost all the Samsung 8* and various Crucial models) that will permanently delete the wrong data ('https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/') when issuing TRIM commands.

The bug is not dependent on queued TRIM, it happens even when using the non-queued version.

All the Samsung SSDs beginning with a "8" (840 and 850, both EVO and Pro) are known to have the data-destroying TRIM bug and TRIM is blacklisted on those drives on other platforms.

I haven't looked into it too heavily and I know that plenty of people use TRIM with these drives with no issues (I did in the past), but given that I use a Samsung 840, it gives me pause about enabling this feature. Just figured I'd put it out there for everyone else to see.

Someone over at Ars Technica posted a warning about using TRIM with certain hard drives. I'll quote it here:


I haven't looked into it too heavily and I know that plenty of people use TRIM with these drives with no issues (I did in the past), but given that I use a Samsung 840, it gives me pause about enabling this feature. Just figured I'd put it out there for everyone else to see.

So far there is no evidence indicating that the issue exists outside Linux. There are plenty of users running Samsung SSDs in Macs with TRIM enabled and I've yet to hear a single data loss issue.

My TRIM tutorial has been updated to cover OS X 10.11 El Capitan, OS X 10.10.4+ Yosemite, and OS X 10.10.3 Yosemite all in one place:

https://github.com/Temptin/Documents/blob/master/OSX_TRIM_Tutorial.md

---

About Cindori's Disk Sensei and Trim Enabler:

I can already see the confusion growing due to Cindor's intentionally vague statements. The method that Cindori (Disk Sensei/Trim Enabler) is bringing out is *identical* to the "trimforce" command method in my guide. He has created his own .kext file that injects the "Force Data Set Management = YES" option in the exact same way as the official extension. His method is not "safer" at all. It's the exact same thing; with one small difference: He installs the injector to /Library whereas the trimforce tool installs the injector to /System/Library - and the latter is protected by "rootless" on El Capitan, but that seems like an oversight on Apple's part. Either way, you can easily disable rootless, run trimforce, and re-enable rootless on the current El Capitan beta (instructions for that are in the link above). Moreover, it's very likely that Apple is going to fix it before release so that you don't need to even temporarily disable rootless to run trimforce.

I'll say it one more time: There is no reason whatsoever to use Cindori's injector instead of Apple's injector; they do the *exact* same thing. I even suggest using Apple's since they're the ones who created the method, and if any of the implementation details ever change they'll be the first to update their official kext.

There are plenty of reasons to use Cindori's Disk Sensei: Disk space visualization, benchmarking, SMART health monitoring, various tweaks to prolong SSD life (like "noatime"). "TRIM enabling" is no longer a reason to own the tool.

---

As for people's questions about TRIM, GC, etc, I refer to these posts:

* Do we need TRIM? Does OS X use Queued TRIM? Do Samsung 8*-series SSDs break when TRIM'ing?: https://forums.macrumors.com/threads/os-x-el-capitan-opens-door-to-trim-support-on-third-party-ssds-for-improved-performance.1891936/page-10#post-21469307

* About Garbage Collection vs TRIM: https://forums.macrumors.com/threads/os-x-el-capitan-opens-door-to-trim-support-on-third-party-ssds-for-improved-performance.1891936/page-10#post-21469409

* Does TRIM work with Filevault 2 Full Disk Encryption?: Yes ('http://apple.stackexchange.com/questions/26961/does-filevault-2-interfere-with-trim-when-using-an-ssd'). Apple's FileVault driver sends the "TRIM" command to the disk, and zeroes out all unused blocks.

* Does TRIM work with Apple's Software RAID?: No. Their software RAID driver was last updated in 2009, and OS X didn't get TRIM support until mid-2011. Apple's RAID driver has no idea what TRIM is and does not send TRIM to the SSDs in your RAID. OS X cannot simply "pass through" commands to the underlying SSDs (as some people have wrongly assumed), since a RAID means that data is split across multiple drives, which means the OS has no idea "where the data is and which drive to TRIM in a RAID," - it's always the job of the RAID driver to re-map the TRIM requests to the real underlying drives and blocks, and Apple's RAID driver is over half a decade old and doesn't do that job at all. If you are using Apple's software RAID, TRIM will NOT take place (your individual drives will still say "TRIM Supported: Yes", but nothing will be done).

I should probably put all of this information into the TRIM guide document itself, since people bring up these misconceptions over and over again.

Mac OS X 10.10.4 Supports TRIM for Third-Party SSD Hard Drives

Solid State Drives Hard Drives? Really?

Yeeeeeeeeeesssssssssssssssssss! FINALLY! Just turned that sucker on.

OWC drives don't require TRIM as they have their own garbage collecting tech built-in.

http://blog.macsales.com/21641-with-an-owc-ssd-theres-no-need-for-trim

GC is not the same as having native TRIM support. With the change to Yosemite originally (no more TRIM without disabling kext signing) I imagine OWC saw the potential for lost sales so they put out that article to put people at ease.

Now that TRIM support is back, you can enable it for that drive. The built in GC is no substitute for the TRIM system.

If you keep the SSD mostly empty anyway then the benefits are marginal for most people. If you have a smaller SSD though, or like to fill it up nearly full then you'll benefit enormously from native TRIM on any SSD.

Erm, technical knowledge challenged "Finally" crowd, for your consideration:
http://linux.slashdot.org/story/15/06/16/201217/trim-and-linux-tread-cautiously-and-keep-backups-handy

I eagerly await your fists of rage flying into the air when your SSD that does a ****** job of implementing disk controller commands borks your data. (You see, Apple was cautious about this because they had the muscle to make hardware manufacturers do it right with Apple supplied parts. Good luck with your 840 EVO. The command comes with a disclaimer for a reason.)

They'll put a stop to this soon. :apple:

Yeah, right after allowing Trim for 3rd party devices, they'll prevent using 3rd party devices at all...:rolleyes:

Actually there are. Essentially though the bug seems to only affect queued TRIM commands which Linux and OS X use - in Windows it sends TRIM commands every once in a while along with data and flushes the queue to prevent issues. Linux and OS X on the other hand expect the drive to manage its own queue properly, which as it turns out, a lot of Samsung SSDs don't do.

I see no evidence that OS X uses or supports queued TRIM commands, even if the device firmware says that it supports queued TRIM commands. It is therefore impossible that the device firmware has a problem with queued TRIM commands.

The results of TRIM are also file system dependent (Linux ext4 vs. OS X HFS+ (Journaled)).

From:
http://www.opensource.apple.com/source/xnu/xnu-2782.1.97/bsd/hfs/hfscommon/Misc/VolumeAllocation.c

/*
* Validation Routine to verify that the TRIM list maintained by the journal
* is in good shape relative to what we think the bitmap should have. We should
* never encounter allocated blocks in the TRIM list, so if we ever encounter them,
* we panic.
*/
trim_validate_bitmap

and

; Routine: hfs_unmap_free_extent
;
; Function: Make note of a range of allocation blocks that should be
; unmapped (trimmed). That is, the given range of blocks no
; longer have useful content, and the device can unmap the
; previous contents. For example, a solid state disk may reuse
; the underlying storage for other blocks.
;
; This routine is only supported for journaled volumes. The extent
; being freed is passed to the journal code, and the extent will
; be unmapped after the current transaction is written to disk.

The HFS+ code uses the TRIM (unmap) command only, if the storage blocks on the device contain no longer necessary data.

What a load of nonsense. There are no TRIM bugs with Samsung 8xx SSDs, or indeed any SSD manufactured in the last 4-5 years.

Actually there are. Essentially though the bug seems to only affect queued TRIM commands which Linux and OS X use - in Windows it sends TRIM commands every once in a while along with data and flushes the queue to prevent issues. Linux and OS X on the other hand expect the drive to manage its own queue properly, which as it turns out, a lot of Samsung SSDs don't do.

Take a look at this article:
https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/

Of note is that the Linux kernel has had a workaround written in for a while now. From the Linux kernel source code:
/* devices that don't properly handle queued TRIM commands */
Micron_M500*
Crucial_CT*M500*
Micron_M5[15]0*
Crucial_CT*M550*
Crucial_CT*MX100*
Samsung SSD 8*

You can see the code in question here:
https://github.com/torvalds/linux/blob/e64f638483a21105c7ce330d543fa1f1c35b5bc7/drivers/ata/libata-core.c#L4109-L4286