Slashdot Mirror
Apple Disables Trim Support On 3rd Party SSDs In OS X
MojoKid (1002251) writes One of the disadvantages to buying an Apple system is that it generally means less upgrade flexibility than a system from a traditional PC OEM. Over the last few years, Apple has introduced features and adopted standards that made using third-party hardware progressively more difficult. Now, with OS X 10.10 Yosemite, the company has taken another step down the path towards total vendor lock-in and effectively disabled support for third-party SSDs. We say "effectively" because while third-party SSDs will still work, they'll no longer perform the TRIM garbage collection command. Being able to perform TRIM and clean the SSD when it's sitting idle is vital to keeping the drive at maximum performance. Without it, an SSD's real world performance will steadily degrade over time. What Apple did with OS X 10.10 is introduce KEXT (Kernel EXTension) driver signing. KEXT signing means that at boot, the OS checks to ensure that all drivers are approved and enabled by Apple. It's conceptually similar to the device driver checks that Windows performs at boot. However, with OS X, if a third-party SSD is detected, the OS will detect that a non-approved SSD is in use, and Yosemite will refuse to load the appropriate TRIM-enabled driver.
See http://blog.macsales.com/21641... for an example of a properly designed SSD.
kext signing is a GoodThing for security. Making the system less secure so that lazy implementors are protected isn't a good trade off.
Apple *should* have provided a better upgrade experience so that users wouldn't be surprised, or end up with unbootable systems. Users that don't want to have kext protection CAN turn it off see http://www.cindori.org/trim-en...
To me this is akin to Apple's desupport of WPS ages ago. It took everyone else a while to figure out that WPS was a major security hole (indeed, its still there for most consumers).
Some SSDs' TRIM support is so broken that its use can actually lead to corruption and other issues. Maybe Apple simply prefers to have users complain about speed than about data loss, IOW it could be cheap but safe workaround.
The Linux kernel, for instance, keeps a blacklist for this issue instead — but one that (commonly) only grows when the devs get reports from somebody who already suffered data loss, and then it takes ages for the new kernel to be used widely in the wild.
It isn't really true that SSD performance goes down by a whole lot if TRIM is not enabled. SSD performance and firmware has undergone radical improvements every year and people have come to the mistaken belief that enabling TRIM is responsible for most of the performance and wear leveling improvements.
TRIM has numerous problems, not the least of which being drives and/or filesystems which do not implement it properly. Because its use and effects can be seriously non-deterministic (even in a proper implementation), any bug in the drive firmware OR the filesystem in the use of TRIM can create serious corruption issues down the line when the drive actually decides to blow away some of the trimmed sectors. The TRIM command was badly conceived from the get-go.
The easiest and safest solution to getting 95% of the benefit of TRIM without actually using TRIM is to simply partition a factory fresh drive to leave a bit of unused space at the end... say another 5-10%. As long as it isn't written to, the drive will use that space as part of its dynamic wear leveling mechanic. As long as the drive also does static wear leveling (which nearly all will do these days), you wind up with nearly all the benefit of TRIM without having to actually use TRIM. TRIM was more important in the days where static wear leveling was not well implemented (or implemented at all). It is less useful these days.
-Matt
The Linux kernel, for instance, keeps a blacklist for this issue instead
This is true. The blacklist is contained in drivers/ata/libata-core.c for anyone who wants to take a look at it.
To find it, in that file search for: static const struct ata_blacklist_entry ata_device_blacklist []
For SSDs with (queued) TRIM problems, that list seems to contain only Crucial/Micron M500/M550. There is a lot of other devices blacklisted for various reasons. Of course they aren't blacklisted completely but just some features are disabled in them.
The real problem here, as I see it, is that the developer of the TRIM enabler is writing bug reports that request a ridiculously complex solution that doesn't make much sense, rather than a very trivial solution that does.
The right way to solve this problem would be for Apple to add a single line of code that checks for a magic value in the device tree, and enables TRIM support if it finds it. Then, the TRIM enabler could write a codeless kext for any devices whose TRIM support seems to work, whose sole purpose is to add that magic value into the device tree, that matches at a higher priority than the Apple driver, modifies the device tree, and walks away from the table, allowing the Apple driver to attach, see the flag, and use TRIM support.
Heck, there's probably a flag like that in there already. Just looking at the device tree for my Apple-branded drive in 10.9, I see something pretty glaring:
"IOStorageFeatures" = {"Unmap"=Yes}
and thirty seconds later, found the documentation for that key here. Chances are, if you write a codeless kext that modifies the device tree to add this property to the device, and if you get your matching correct, the unmodified Apple driver will magically enable TRIM support. If so, then you just need to get a proper signing key from Apple, sign the codeless kext, and you're done. If not, file a bug asking for that approach (or a similar approach with a different key) to work.
If that approach doesn't work, then and only then should you even think about writing an actual chunk of kernel code.
Check out my sci-fi/humor trilogy at PatriotsBooks.