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.
Apple loves their walled garden, but doesn't make decisions like this capriciously. Until we know *why* Apple's doing this, it's hard to judge the situation. They may have a reason that seems insignificant to the end user, but you don't get to be the biggest company on the planet by making decisions like this for no reason.
Ask me how the Heisenberg Principle may or may not have saved my life.
If you read the rest of the article, you find that you can simply disable the driver loading security to have it working again.
The article paints this as a huge security issue, but why? Anyone putting in a custom SSD is also probably technically astute enough not to download a KEXT that ostensibly puts a cat following your cursor or what have you.
Cn anyone reasonably argue that having a system highly secure for non-technical users with easy workarounds for actually technical users is a bad compromise? The people who are not technical need all the help they can get.
Also - couldn't you actually just sign the drivers that are needed for trim? What prevents that?
"There is more worth loving than we have strength to love." - Brian Jay Stanley
No, it's a flat out lie.
TRIM support has been baked into Windows and OS X for long enough that new SSDs aren't typically tested to evaluate the impact of not running TRIM has on the drive.
Apple has long had a history of only enabling TRIM for Apple drives by default.
Read TFA. They enable trim by default for preinstalled SSDs and disable it for everyone else.
It can be done if you're willing to disable kext security check
see http://www.cindori.org/trim-en...
Apple has never enabled TRIM on non-OEM SSDs, which is probably the conservative and correct thing to do. If you're clever enough to install a new SSD, you're clever enough to enable it on your own (and presumably to know whether you should enable it, and whether it's even a benefit for your particular drive).
The current workaround involved a single software vendor who didn't sign their kexts. Apple's new security policy won't let you load random unsigned kernel modules unless you explicitly turn off the signature checking. While this is inconvenient for me personally - because I have a 3rd-party SSD and I used that software myself - on whole, I'd rather have a more secure OS than the dubious benefit of a possibly slightly faster SSD.
Dewey, what part of this looks like authorities should be involved?
It always amazes me that people still try to bash Microsoft over the (bad) things they did in the 90s. Apple has become everything we always feared Microsoft would be, but without all the backlash and bashing. This is truly a "We're not done until 3rd party stuff doesn't work" situation that everyone always suggested MS had (and MS probably did have to some extent). They are purposely disabling an industry standard for anything other than their drivers to force people to use their overpriced upgrade hardware. Yes, you can disable this "feature" but to do so you have to disable ALL driver signing on the system, thus removing a big security protection. Apple is by far one of the worst companies as far as policies and screwing people, and yet no one ever seems to say much about it even as people still write Micro$oft. Maybe it's because there isn't a cute little way to put a dollar sign in their name.
"Information wants to be expensive" - Stewart Brand, the same guy who said "Information wants to be free"
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).
that are needed for trim? What prevents that? Likely just time. But that doesn't make for an alarming headline.
"Win treats sysadmins better than users. Mac treats users better than sysadmins. Linux treats everyone like sysadmins."
My comment was in regard to "3rd Party SSDs in OSX." and is thus true. Apple has always disabled TRIM on those. You can even see Other World Computer (a primarily Mac related retailer) reference it in a blog post on their SSDs back in 2013. It's not a new thing with Yosemite. Only the stricter driver signing checking is new.
Apple, for whatever dumb reason, has _never_ enabled Trim on non-Apple branded SSDs. I do not know of any HDD manufacturers that ever provided any kernel extensions that would enable Trim for their drives, so effectively, third-party SSDs have never had any official trim support on OS X.
Before Yosemite this has never been an issue. Any user who was able to install their own SSD could also download the handy TRIM Enabler software that forced Trim on for non-Apple SSDs. One toggle switch, one reboot, piece of cake. I've been running multiple Macs since OS 10.6 with multiple brands of SSDs (OCZ, Samsung, Intel, etc) with absolutely no issues and no signs of performance degradation.
The difference in Yosemite is, as the summary says, non-signed Kernel extensions cannot be loaded by default. Since non-signed kexts are blocked, software like Trim Enabler cannot load. You CAN override this behavior, but there are potential issues (see the Trim Enabler site for more information).
There is absolutely no reason to believe that the decision to make Yosemite require signed kexts has anything to do with the status of trim on non-Apple SSDs. I doubt trim even crossed anybody's minds during the decision-making process. Trim Enabler is just an unfortunate casualty of kext signing (which itself is probably not a bad thing!).
tl;dr -- a rather hysterical take on an issue that DOES display some Apple stupidity. Just let us enable trim on non-Apple drives natively and there's no problem!
Sell your Apple stock now. Apple has plateaued.
hadn't shown multiple vendors who can't implement TRIM properly. Like the very popular SSD vendor whose firmware treated any TRIM as "TRIM all blocks" several years ago. Or the currently-shipping vendor whose firmware causes TRIM to delete a random block.
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
At least for the MacBook Pro's there is. As far as the MacPro's themselves, the fans are so quiet and unobtrusive and the system runs so cool I haven't found any particular need for them.
Faster! Faster! Faster would be better!
Apple has introduced features and adopted standards that made using third-party hardware progressively more difficult.
If they're adopting standards, then shouldn't that make using third-party hardware easier, since that hardware merely has to be standard-compliant?
Always, in the context of this discussion about third party SSDs. Apple has always disabled TRIM support on them. What's so hard to understand about that? It's been a known fact for the past five years.
Do you know if this applies to the Samsung 840 EVO series?
Seriously, look at this fellow's posts. Doesn't matter what Apples does, it is not their fault, or it is their fault but it's Apple, so there is a good and just reason.
I just understand this mindset. TRIM has been around for a long time now and it works. Plain and simple. It has worked perfectly on my mac after I enabled with a 3rd party hack.
No, this is only a clamp down in order for force you to buy their SSD for double the price.
I am 100% positive if MS sold SDDs and suddenly blocked TRIM, this turkey would be screaming at the top of his lung about power grabs and anti-competitive actions. But, since we are talking about Apple....
I've done it on certain iMac moddles without any additional software by purchasing an additional temperature sensor and plugging that in instead of plugging the Hard Drive temperator sensor into the 3rd party SSD. ^_^
sudo nvram boot-args="kext-dev-mode=1"
As to "why doesn't the developer sign his extension": the TRIM enabler hacks out there are just that, hacks. They all set a given string of "APPLE SSD" to all null characters.
I think you might "literally" be "retarded".
Get your driver signed
By whom? Can the owner of a Mac choose which code signing certificate authorities to trust? If not, how does that inability benefit the computer's users?
When you qualify it by saying, "always on third party SSDs", then it's not the same as "always" (unqualified).
But he did:
Apple has always disabled TRIM on those
So, what's your point?
The latest episode of ATP (www.atp.fm), they heard from an Apple Engineer that Apple disables it because most makes of SSD are very inconsistent on how the TRIM command is executed. And Apple being Apple, they don't particularly want to try every SSD known to man to "support" them.
Best bet is to use a drive with a controller than does it for you. I'm sporting SSDs from OWC and I haven't had any issues in speed and I've had them for over two years now.
It's either on the beat or off the beat, it's that easy.
I moderate therefore I rule!
--
No, you couldn't, since they are Apple's drivers not yours. Apple's driver takes over handling of external drives, but it refuses to TRIM them. Previously, people worked around that by patching the driver, but signing prevents that.
And more to the point, this is nothing new and it has ALWAYS been this way.
Apple has ONLY EVER provided trim support for SSDs that have Apple in vender name of the drive as returned by whatever the IDE command is that returns that info..
The difference here is that the author apparently just discovered that drivers in OS X are now signed, as such you can't use the old HACKs to enable Trim on non-Apple SSDs. The hack simply edits the Apple AHCI driver to look for a different string in the vendor name, which will then enable trim for that other type of drive. At no point did Apple sanction 3rd party SSD usage or support trim on those drives.
This isn't even new to Yosemite, Mavericks had driver signing as well. The only difference is that Yosemite switched to require signed drivers by default ... you know, LIKE EVERY OTHER SANE OS ON THE PLANET.
The very simple solution is to just provide your own signed driver if you REALLY want your 3rd party SSD to support trim on OS X.
This really only affects people who want to go buy an Intel SSD from some cheap place and slap it into their OS X machine. If you're buying an SSD from the one place to buy OS X SSDs that are 'supported' by the vender ... you go to OWC ... who uses SSDs with Sandforce controllers ... that don't need trim in the first place due to their intelligent way of doing garbage collection and keeping a portion of the drive reserved for this purpose.
Yes, buying anything with Mac support is more expensive. Don't like it? WHY THE FUCK are you buying a Mac? Macs are not for cheapskates, and never have been.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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.
kext-dev-mode=1
Sandforce controllers ... that don't need trim in the first place due to their intelligent way of doing garbage collection and keeping a portion of the drive reserved for this purpose.
Seriously? I'd love to hear how you imagine that works.
Without TRIM, the SSD eventually considers all user-visible sectors to be in use. As a result, a sector is never just empty ready to be written. Even with reserved space, it still has to copy the entire much larger erase block in order to insert one sector.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
I think I will make apple product owners wait 3 extra rings before answering.
Maby I can even move non apple users up the queue. That'd be fun!
The generic MS drivers know how to see if the drive supports TRIM and send the commands if it does. That's the point of TRIM: It is an ATA standard command, so special software isn't needed.
In fact, in Windows all you use is the generic drivers. I mean you may install drivers for your SATA controller, but not for your drive. My laptop has a Samsung 840 Pro in it, with Samsung's Magician installed. However the drivers in use are disk.sys, partmgr.sys (both Microsoft files) and iastorf.sys (Intel's file). No Samsung provided drivers. Magician can directly send commands to optimize the drive if needed if the OS can't, but the OS sends TRIM commands no problem.
You wasted your money. Apple themselves simply eliminate the temperature sensor when an SSD is installed, as they run cool no matter what. All you need to do is to short out the sensor input (as Apple do) and the system keeps the HDD fans ramped all the way down. This works on the iMac, not sure about the Macbook.
Yes... the demented world of Apple where daring to buy a 3rd party peripheral is only for "power users" or "cheapskates" or some other class of person that will be denigrated by the hive mind.
THIS here is the biggest reason to avoid Apple products. Not the price. Not the novelty form factors that cook your machine. Not the fact that nothing is maintainable.
It's THIS attitude here that anyone that's using this "platform for creatives" in a remotely creative way will get shouted down by the hive mind.
A Pirate and a Puritan look the same on a balance sheet.
I've not checked if things have changed, but I seem to recall that Ubuntu only enable TRIM on known good drives. The reason being that there were a number of problematic drives that would result in data-loss if TRIM was used.
So.... maybe Apple are being cautious?
I've been primarily a Mac user since 1999 or 2000, and I've watched the serviceability of Apple's machines go back and forth over the years. Before they moved to the Intel processor, you often had very limited options to do anything with the configuration you purchased, even when the machine in question was a tower type desktop computer. RAM was generally not an issue, although Apple sometimes required very specific timing for the DIMM modules - limiting what you could put in. But certainly, upgraded video was a problem (very limited in which cards could be used as upgrades - including cases like the G4 Cube where some cards were physically too long to fit, even if they'd work otherwise). Laptops like the iBook G4 were notoriously difficult to take apart for service. I remember replacing a bad hard drive in one for a guy I used to work for, and it was at least a 2 hour long job for me with screws all over the place. After that, I understood why repair shops would quote such high labor rates when you asked about an iBook repair.
Then I watched things go the opposite direction. The newer Macbooks and Pros became increasingly easy to work on, so you could unscrew the bottom plate and have instant access to everything -- or just remove a small plate to get to the RAM slots. Batteries became removable from the bottom by just sliding an unlock switch. Even the iMac was easy to upgrade at one point (hard drive right there once you took the back cover off, and no need to do more than unscrew a couple screws on the bottom to get to the SO-DIMM memory).
But it's now swinging back to the "non serviceable" mode again, with the pentalobe screws trying to keep people out, soldered RAM on the motherboards, and having to take the whole glass and LCD screens out of iMacs to work on them.
Truthfully, I don't think the TRIM support for non-Apple branded SSDs is that big of a deal. It's been known for quite a while now that Apple wasn't including TRIM support for 3rd. party drives -- and there's even one 3rd. party SSD coming out now with TRIM functionality built into its firmware, so OS X doesn't need to have support to do it. You can turn off the feature in OS X that verifies you're only using signed KEXTs and get the custom ones to work for TRIM support too.
But sure, it's annoying .... and I'm not going to make apologies for Apple about any of this. We still use their products where I work and none of this will make us stop. (As long as you have a warranty, you just hand it back to Apple when it breaks and it's their problem. If you still need it and the warranty is up? Fine... you pay up and let Apple service it and hand it back to you again. Their repair prices have actually gone down in recent years, as they've made more products reliant on them to service them.) Home users are the ones who get the short end of the deal though, as money is more of a problem for us and we tend to buy lesser configurations of machines to save money up front -- intending to add to it later. With Apple, that's becoming a poor decision.
"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".
Do please explain the logic in Apple not making it's own hardware working the best with it's own software and why there is nowhere on the planet where we can buy a 'traditional PC OEM' without Microsoft Windows being unwanted and included and why slashdot doesn't deem this as total vendor lockin.
TRIM says 'I won't read back from this sector, so you can erase it whenever you want'. That makes it a bit easier for the wear levelling to work. It isn't essential though. An SSD controller can remap sectors at will. Typically, it will keep track of the age (number of erase cycles) of each cell and the time of the last erase. Once a cell reaches a certain age it will write some old (and therefore hopefully infrequently changing) data onto it. Current SSDs, because of the low reliability of individual flash cells, over provision by quite a lot, so it's relatively easy to structure the writes so that everything is a copy. This doesn't even affect performance, as the reads and writes can happen in parallel. The only thing that hurts performance is if you need to block a write waiting for an erase to finish.
I am TheRaven on Soylent News
The reason that Apple disabled this is that a lot of SSDs have really buggy TRIM implementations. This observation wasn't unique to Apple: Microsoft and the Linux kernel defaulted to TRIM being off until quite recently. Apple could afford to turn it on for their own SSDs because they did extensive compatibility testing of those before shipping them.
Now, it doesn't really make sense, but enabling it automatically would likely burn some users, and bug reports about data loss lead to a lot more anger than bug reports about lower performance.
I am TheRaven on Soylent News
"The latest batch of high-performance Solid State Drives will last longer and perform better down the line in a Windows PC than a Mac PC!"
No, you couldn't, since they are Apple's drivers not yours. Apple's driver takes over handling of external drives, but it refuses to TRIM them. Previously, people worked around that by patching the driver, but signing prevents that.
Right, but drive vendors could sign a driver and supply it with the hardware, they just choose not to do so because the vast majority of bare SSDs are sold for Windows boxes where Microsoft's driver is not picky about TRIM support.
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.
That's nice. Except there's no such thing as an Intel-Platform-SSD and an OSX-Platform-SSD.
Yes, there are SSDs manufactured by Intel. But that's irrrelevant.
Basically this is a stupid driver+firmware hack by the Cupertino Turtleneck Crew so that if someone wants to buy a third party SSD and put it into their system, Apple can penalize them by eventually destroying the performance of the drive, simply by preventing it from doing what is now a common housekeeping function on all modern drives.
And this happens whether you buy a quality drive OR NOT.
So it has nothing to do with drive cheapness.
It has to do with Apple being giant, flaming schlongs.
Chas - The one, the only.
THANK GOD!!!
No, you couldn't, since they are Apple's drivers not yours. Apple's driver takes over handling of external drives, but it refuses to TRIM them. Previously, people worked around that by patching the driver, but signing prevents that.
Yes, you can. People are already making kext-modification scripts and other tools that get around the signing.
This is pretty much a non-issue.
Apple didn't disable TRIM. They just tightened up security around Kernel modifications.
I did 3 things to my desktop in October.
1.Updated it to OSX10.10
2.Bought and installed my first SSD.
3.Installed a 3rd party TRIM driver and in doing so switched off OSX10.10's kernel security so it would be unhindered.
Then I read today "Apple Disables Trim Support On 3rd Party SSDs In OS X".
Talk about BS...
Slashdot.org should be renamed "linuxandroidgeek.religion"
It's pathetic, it's bad enough with main stream media having political bias without technology media getting all one sided.
It's not illegal at all. As long as Apple doesn't claim that using the 3rd party SSD voids the warranty on the machine as a whole, they're in the clear. They're under no obligation to warrant the 3rd party SSD works.
I have a 2009 Macbook running Yosemite. Note this machine was not available with SSD at the time it was sold. A year ago I decided to put an SSD in it, and being aware of the TRIM issue, I made a point to buy a secondhand *Apple* SSD from a Macbook Pro. Neither Mavericks nor Yosemite will enable TRIM on this machine.
So apparently, not only will OS X not enable TRIM on a non-Apple SSD, but the machine *must* be a model for which there was an SSD option at purchase.
Citation needed. Both the built-in msahci and the intel-ahci-drivers in Windows are NOT restricting TRIM in any way.
Your posting is a disgrace to the world of computers.
The situation is the same that has been since apple supports TRIM, the only difference is, like other says, that to make 3rd party SSDs work with trim you'll have to disable device signing. That is not a "huge" security risk since that is a feature that you have from 10.10, so you are exposed to threat as you where before 10.10.... Plz remember that to disable kext signing you need the same privileges you need to replace a modified kext, so I don't see kext signing useful at all, and I disabled it on my two macs (both with 3rd party SSDs) that happily TRIM under 10.10....
You are entirely correct if we are speaking of the standard, non-queued version of TRIM. There is no valid technical explanation for not issuing that to third-party SSDs, no consumer will blame something other than the crap SSD if that malfunctions. But standard TRIM requires the entire queue to be drained, so it really should be done only in "batch mode" when the filesystem is otherwise idle, not synchronously.
However, if Apple decided to issue the queued version of TRIM (yes, it exists, and Linux uses it), you will quickly find that you REALLY should not trust SSD makers other than Intel in the desktop market, and a *few* selected vendors in the enterprise market, *ever*.
while that I/O operation is being done, that's going to mean some other I/O operation isn't
There are plenty of times that a disk isn't actively in use. Say you stand up and get a coffee or use the toilet, and your PC is either idle or in the middle of a CPU-bound task that doesn't use a lot of disk, and it's plugged into its AC adapter (so that you aren't wasting battery power). During this time, your file system can either trim or zero out recently deallocated sectors without noticeably affecting other applications that use the disk.
For small erase sizes, writing zeros would be much, much faster if only the SSD spec specifically stated that writing zeros would have a TRIM effect. But it doesn't.
Some SSD makers' specs do state as such. See this description of how the controller in an OWC SSD works, which I found via this comment to the present story. The DuraWrite feature of SandForce SSD controllers stores trailing zeroes in a sector with a more efficient compressed encoding, which reduces write amplification in the same way that TRIM does.
Yes, but that requires the filesystem to zero out all redundant data.
The difference is that zeroing is well defined even on devices that don't support TRIM (such as HDDs) and on devices whose implementation of TRIM is defective.
For performance reasons most filesystems just note that it is unused in their metadata tables.
Then zeroing can be a deferred background task, much as TRIM is. So if Apple restricts TRIM to only those SSDs where it has comprehensively tested TRIM, Apple could add a policy of background zeroing on other drives. It could even play up the feature as "More secure Trash" or something like that.
You wasted your money. Apple themselves simply eliminate the temperature sensor when an SSD is installed, as they run cool no matter what.
I didn't see it that way; it was a $15 piece anyways.. it would have been extra work to cut up the temperature sensor wires, splice and cap them, and this would ruin the reversibility of my change, in case I need to go back and claim warranty. If I had bought the Apple part instead of using my own, it would be an additional $400 or $500 for a 260gb SSD.
Can't you read or are you deliberately lying? From the very page you point to:
As I was saying: signing prevents modifying kernel extensions. That's the whole point!
When I saw the title of the thread I just knew. This behavior is total unacceptable and would be considered anti-competitive if another company did it, but I just knew that this thread would be full of Apple apologists trying to explain that this was OK because Apple. I was right.
What other company would you give a Big Thumbs Up to for refusing to install drivers for third-party hardware because SOME drivers MAY be implemented poorly? Or make it difficult to install a competitor's software? Microsoft? It was a major scandal that they INCLUDED their own software (IE), let alone if they were to actively suppress the competition's.
It's unclear that they could even if they wanted to. The Apple driver is already managing those devices and they all go through the same controller. In addition, writing a good storage driver is a lot of work, work third party vendors shouldn't have to go through just to add a standard piece of hardware to a system.
This kind of deliberate incompatibility is nothing new either. Apple was playing the same games with incompatibility of disk drives back to early Macintosh days.
I got a Wintec ExpressCard SSD for my 17 inch Macbook Pro and suffered through multiple rounds of filesystem corruption before realizing it's caused by trim enabler. I think this is a correct decision for vast majority of users. For the rest, there is an option of disabling kext signing.
DISCALIMER: This is a personal, nonprofessional opinion. It is not legal advice. Ask your lawyer. I am not one.
Specifically adding code to diminish capability without adding any counterbalancing benefit sounds like restraint of trade to me. In the USA, that's illegal.
Angelbird SSDs have native Mac TRIM support, I upgraded my MacBook Pro with an Angelbird SSD wrk for Mac, I've updated to Yosemite and it confirmed in the System Settings that TRIM is enabled, which is very important for conserving the life of the SSD. http://www.macrumors.com/2014/...
So disable the kext signing and stop crying.
sudo nvram boot-args=kext-dev-mode=1
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
Wear leveling is only part of the picture. Whenever the SSD erases a block (for wear leveling OR because one sector in the block has been rewritten) it empties any sectors in that block which have been trimmed. The next write to an empty sector requires no erase and copy, thus it's far faster.
Without trim, a visible sector, once used, is never again empty. This means that every write requires a block copy and erase.
I haven't heard of any SSD remapping sectors as opposed to remapping full blocks. Not saying it's impossible, just that I don't think it's generally done. In principle you could journal sectors to a non-user visible area and then do your copy/erase activity when the drive is reasonably idle. But the description of the Sandforce controllers I read suggests it doesn't have the necessary hardware for that.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
I'm the developer of Trim Enabler.
What bug reports are you referring to? I am not writing any bug reports. Some Mac users feel obliged to send requests to Apple about removing the Trim 3d party SSD limitation, but I got nothing to do with that.
You should understand that the problem of Trim with 3rd party SSD's is not that Apple didn't add support for it, but that they intentionally DISABLED support for it. The driver checks if the SSD is manufactured by Apple, and if not, disables the Trim feature.
I've already tried making injector extensions, and it does not work. You can inject the Unmap key or even change the model name of the drive, but the behaviour is unchanged, which means the check is done internally in the block driver and not via IOServicePlane. In any case, it is a dead end anyway, since I don't think Apple would grant a kext certificate for an injector kext, so we're back to square one.
Mod AC up as insightful and informative.
It's a declarative sentence, the scope is global unless a clause is used to restrict it. Likewise, the use of "this" (as pronoun) in this context requires that the noun to which is refers be used *in the same sentence* because otherwise it renders the sentence so ambiguous as to be useless -- two people can read the same sentence and come away with opposing messages.
You can't go back to square one, it hasn't been cleared for rewriting yet.
It's a declarative sentence, any conditions narrowing scope should have been included in the (absent) part of the sentence called a clause. You're confusing written English with conversational English. That sentence would have been read and understood if one person said/typed it to someone else during an interactive conversation; using that type of sentence structure on a forum/group conversation thread is ambiguous and can lead to multiple contradictory meanings.
TRIM is already implemented in firmware; what the OS sends to the drive are "hints" indicating blocks which have become free and require clearing. Without the OS sending those hints I don't see how the SSD would know which blocks are safe to clear; doing so requires reading the drive's file system, which is why the OS has always been involved.
my panties were all in a bunch and you had to come be reasonable do laundry for me and ruin the article.
You're right. SSD controllers are extraordinarily complex. Buggy implementations leading to issues makes perfect sense.
Getting "permission" to sign a KEXT (from Apple)
What gives Apple the right to decide what one can do with their computer? If I want to allow a particular KEXT to run, I should be allowed to. Microsoft asks for every unsigned driver if I wish to allow the installation. Why can Apple not support driver approval by the user? Or does Apple actually believe that it knows better?
Because Apple's support includes supporting the entire solution - hardware and installed OS. When things go wrong they'll actually work with you to fix them rather than simply pointing fingers. Naturally this gives them a really strong incentive to make sure that both of those item continue to work in harmony; part of their approach to that is restricting the more arcane things that the majority of end-users don't have enough experience to do safely.
For anyone who has enough experience to know when to accept an unsigned kernel extension, there's a trivial command to allow it; I happen to agree that people who can't figure out how to enable unsigned drivers really shouldn't be installing them.
You're special forces then? That's great! I just love your olympics!
Nobody is forced to buy their stuff. People who choose to buy deserve being treated like this.
It is pretty clear what apple thinks of their users, and they are right.
Yup. Apple thinks that their users are the kind of people who value a machine that doesn't randomly lose all of its data after an SSD upgrade and don't want to spend the time to do the brand research themselves, rather than the kind of people who desperately value a .03% gain in SSD performance after said upgrade.
Apple happens to be pretty much right about that. Even as a developer, one of the reasons that I prefer Apple kit to code on is that I don't have to worry about working on it as well as what I'm supposed to be working on.
You're special forces then? That's great! I just love your olympics!
Can't you read or are you deliberately lying? From the very page you point to:
I can read quite well, thank you. But you seem to be having trouble. I was replying to this:
Also - couldn't you actually just sign the drivers that are needed for trim? What prevents that? Likely just time. But that doesn't make for an alarming headline.
No, you couldn't, since they are Apple's drivers not yours. Apple's driver takes over handling of external drives, but it refuses to TRIM them. Previously, people worked around that by patching the driver, but signing prevents that.
The reason I replied was that you are WRONG. Yes, you can. Or rather, you can simply bypass kext signing. It's easy enough.
To continue to use Trim Enabler and continue to get Trim for your third party SSD, you first need to disable the kext signing security setting.
... but apparently, you conveniently stopped there, rather than reading further where it said "Trim Enabler 3.3 will disable the kext-signing setting automatically for you..."
As I was saying: signing prevents modifying kernel extensions. That's the whole point!
And as *I* was saying, it's ridiculously easy to bypass. So technically no, you can't "sign your own drivers", but you can get around the requirement that they be signed at all. That's even easier, and the point I think GP was getting at.
--Technical question that I just thought of: Can this TRIM issue be worked around just by installing Linux as a secondary OS (or booting a liveCD) and just running TRIM against the drive from there?
/hope so
.
== WolfriderV6 == I'm willing to admit that *I just might* be wrong... Are you??
That is true, but it ignores the important half of the picture.
Solid state drives do not write to individual LBAs or sectors. They write to pages, which consist of multiple sectors.
E.g.: If page 1 contains sectors 1-8, and you want write to sector 3, then it has to read sectors 1-2 and 4-8. After doing that, the drive will write the updated contents of sectors 1-8 to page 1 using whichever flash cells it deems appropriate.
It could use the same flash cells, or it could remap those LBAs to cells which have not been used as much (aka, wear leveling). Note that most HDDs present 4K sectors, while newer SSDs use 2M pages---this means the sectors:page ratio is actually 512:1 for most drives.
The drive does not understand deleted files; that is a function of the file system. The drive firmware only knows that those sectors contain data, and so that data will be preserved during future writes. This is the cause of write amplification, which TRIM reduces in order to extend the usable life of the drive.
The TRIM command is the only way to free those LBAs so that the drive will not reread and rewrite them every time it needs to update other sectors in the same page.
The performance impact of TRIM is huge once all pages have been written. In normal desktop scenarios, it might not be noticeable because the SSD will still be immensely faster than a mechanical drive. But in an enterprise environment where SSDs are used for tiered storage or cached writes because you need all the I/O you can get, disabling TRIM could bring down the whole virtual infrastructure.
---
According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
Illiterate, apparently.
No need to apologize.
No, signing does not prevent that, because signing can be bypassed. Is this clear? Do I need to state it a couple more different ways?
I read them carefully enough.
Might want to go away, asshole.
Pardon my reply above.
To me, it looked like a sarcastic comment aimed at me.
But I could have been wrong.
If you could actually read my mind, you would know why you were wrong about that.