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.
You SOLD someone an 11 year old notebook? You're a jerk.
Hard drives preloaded with malware would be a problem, but that's not what this is about. Hardware drivers run as part of the operating system kernel. If you get malware (or just buga) in your kernel, you're screwed. There's no way for any anti-malware system to detect or remove it because the security software has to get it's information from the kernel. So it is very important to protect the kernel.
In order to protect the kernel from malicious or crappy code, it won't load any untrusted modules as part of the kernel. Since device drivers are kernel modules which become part of the kernel, they must be trusted (signed) or they aren't loaded.
So there is a balance here - there is a good reason to not run any random code as part of the kernel, but that has the effect of using only the default OSX driver unless the drive manufacturer gets their driver signed. That means drive-specific features don't work without a signed driver.
Unfortunately, drive manufacturers screwed up trim support, so it ended up being a drive-specific feature. You can't just call trim() per the standard without knowing how that specific drive handles it. Some drives will lose data if you do.
At the endof the day, that's the cause of the problem - drive manufacturers sold hardware that would lose data if used according to the standard.