Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
i ran a Samsung 830 for 3 years with trim and never noted problems.
now i use an 840 EVO, so further info would be appreciated.

EDIT: the 840 evo has the newest firmware and runs yosemite
with trim enabled for 2-3 weeks now. no problems visible.

so we now can assume that at least up until OS X Yosemite only the sequential trim command is used.
 
it (data corruption) appears to only happen if queued trim is used. I was not aware that there's more than one way to issue the trim command. SSDs which are blacklisted in linux then use sequential trim without any loss of data. the big question now is: how does OS X issue the trim command? sequential or queued?

BTW: all thunderbolt cases I know do forward the trim command.

That confirms the theory the bug is a race condition. Non-queued TRIM (the kind before 2012) requires the entire queue be flushed and empty before the TRIM command is handled, therefore there'd be a delay before any other command is processed. (This is also why TRIM on older drives can also counterintuitively negatively affect write performance, even if no other firmware bugs are present but the seem to be present on all SSDs that use SandForce controllers. Either way, the benefits of TRIM on OS X are largely placebo)

As for Thunderbolt enclosures forwarding TRIM, it entirely depends upon the bridgeboard chipset used, the same as other interfaces. It may be that most Thunderbolt ones do indeed support it. In searching, I see various people saying TRIM is not available on their Thunderbolt connected SSD but then never name the manufacturer or model of the enclosure. It also seems some TB enclosures might just use Thunderbolt->To another interface (USB or FireWire)->SATA, using something like an Oxford 946 chipset (which doesn't seem to support TRIM) to reduce costs.

Edit: In the hope of reducing any confusion, just because an SSD came out in 2012 does not mean it supports the SATA 3.1 Queued TRIM command as it usually takes a decent amount of time before manufacturers adopt new versions of standards.
 
Last edited:
so we now can assume that at least up until OS X Yosemite only the sequential trim command is used.

As it is a race condition most likely to appear under high I/O, isn't it entirely possible that queued TRIM is used but the conditions needed to trigger the bug haven't been met yet?
 
extract from https://en.wikipedia.org/wiki/Trim_(computing)

Trim has been defined as a non-queued command by the T13 subcommittee, and consequently incurs massive execution penalty if used carelessly, e.g., if sent after each filesystem delete command. The non-queued nature of the command requires the driver to first finish any operation, issue the trim command, then resume normal commands. Trim can take a lot of time to complete depending on the firmware in the SSD and may even trigger a garbage collection cycle.[citation needed] This penalty can be minimized in solutions that periodically do a batched trim, rather than trimming upon every file deletion, by scheduling such batch jobs for times when system utilization is minimal. This Trim shortcoming has been overcome in Serial ATA revision 3.1 with the introduction of the Queued Trim Command.
 
In searching, I see various people saying TRIM is not available on their Thunderbolt connected SSD but then never name the manufacturer or model of the enclosure.

even after enabling trim in OS X for 3rd party SSDs? the ones I use (LaCie for instance) appear under the SATA/SATA Expess section in the System Profiler as if they were internal SATA controllers.
 
extract from https://en.wikipedia.org/wiki/Trim_(computing)

Trim has been defined as a non-queued command by the T13 subcommittee, and consequently incurs massive execution penalty if used carelessly, e.g., if sent after each filesystem delete command. The non-queued nature of the command requires the driver to first finish any operation, issue the trim command, then resume normal commands. Trim can take a lot of time to complete depending on the firmware in the SSD and may even trigger a garbage collection cycle.[citation needed] This penalty can be minimized in solutions that periodically do a batched trim, rather than trimming upon every file deletion, by scheduling such batch jobs for times when system utilization is minimal. This Trim shortcoming has been overcome in Serial ATA revision 3.1 with the introduction of the Queued Trim Command.

That's the counterintuitive part I love the most. People demand TRIM because they believe it increases performance in all cases (as opposed to only the Windows/NTFS case) while, in actuality, TRIM can incur a severe performance penalty on operating systems that have extremely small (if any) speed hit when not using TRIM like on OS X and Linux.
 
even after enabling trim in OS X for 3rd party SSDs? the ones I use (LaCie for instance) appear under the SATA/SATA Expess section in the System Profiler as if they were internal SATA controllers.

Yup, even after enabling it. I just wish I could find the manufacturers of the enclosures used.

Also remember that various devices will advertise a SATA feature as being supported without actually supporting the command, it's just silently ignored. The biggest example is when external drives are attacked via FireWire or USB, they'll say they support SMART but just ignore the commands or return totally bogus data.

Based the stories I've heard from various Apple (and even PlayStation) hardware engineers, the firmware in SATA drives are huge lying liars with their pants on fire. Every single damn one lies at least once about supporting a command that isn't actually supported or have significant bugs in the feature.

(This was the reason why Apple disabled certain disc writing features on included optical drives, even though the OEM drive itself was advertised as supporting the feature. In the worse cases, if the command was issued to the disc drive, the drive would totally and silently produce a coaster)

To be clear, I am not doubting your experience. I will just never be able to trust drive firmware or bridge boards. (If you look back to the Linux support [search for "ata_device_blacklist"] for various SATA drives, you can see there are a huge number of workarounds implemented for buggy devices)
 
Doesn't matter as even that workaround isn't reliable. Every window expanded that way increases size in a WEIRD non predictable way.

THIS, is how windows should expand when clicking the green button:


Yeah, that's always been one of the very few problems I've had with Mac OS X vs Windows. In Windows, the window resizing is actually predictable, but I have never in my 12 years of using Mac OS X known exactly how the green button worked.

The maker of this video and probably many others didn't actually notice the true function of the little green + button. It is an easy mistake to assume that it is a maximise button when you come from Windows, however as shown in the video, different behaviours occurred depending on the situation. For example, when he opened safari new, and was in the favourite sites view, his safari window didn't resize, but it did when he went onto a website that expanded further down the screen. It didn't go wider though. The reason for this? Because the website wasn't designed to be displayed wider than it was already shown - it doesn't require horizontal scrolling. When the page requires horizontal scrolling because it doesn't fit into the current window size, that is when the window would also widen.

It was Apple's way of making workspaces efficient for multitasking and having windows the required size side by side with one-another.

This is all a little moot now anyway since the green button behaviour was changed to full screen since 10.10. There is however another truly reliable application you can use for maximising windows in 10.10 and below - it's called BetterTouchTool. Requires a small donation but it is the best I have ever seen - adds snapping like what you get in Windows 7+. Reason I say 10.10 and below is because of course in true Apple style they are adding this old feature finally in El Capitan
 
  • Like
Reactions: JustThinkin'
  1. You cannot use the age of an account to determine experience with a system.
  2. I forgot my password for my older account.
You can see that all the Samsung SSDs beginning with 8 are blacklisted from having TRIM support in Linux due to data loss bugs. Googling for these kinds of problems is difficult because they are usually only found in forums or other places that have a robots.txt file denying Google from indexing the site.

The fact you haven't seen data loss issues with your Samsung 840 Pro could mean a number of things.

  1. The data is corrupted but you haven't noticed the problem yet.
  2. TRIM commands are not actually being issued to the drive.
  3. You are extremely lucky and are pressing your luck by continuing to have TRIM enabled.
The best you can hope for in your case is that #2 is happening in your situation.

(And you can of course see other people mentioning non-TRIM related bugs on the Samsung 840 drives in this very thread)

One thing to note, just because Linux doesn't handle TRIM very well (or so it seems by your post), doesn't mean other OSes aren't better at it. This is the problem with Open Source programming - often it is done by people living in their parents' garage or basement. Nothing wrong with that though as there are some truly bright people out there, however same isn't said for everybody. Companies such as Apple however have reputation for only employing people who are a true asset - take all their acquisitions as an example - only the chiefs usually get kept because they have the most to offer.

That said, the statement about the 840 series of Samsung drives being unreliable, I have one and have never had issues yet, in fact after half a year of use it still runs effortlessly, and having moved it from my old broken Macbook to a spare Windows laptop that I have, it exceeds the speeds as quoted in Samsung's Magician software by a large margin. It's all about optimisations, and Samsung did a brilliant job with their software and firmware in this regard, especially for Windows. You probably wouldn't believe me but the windows laptop I have is a crappy Dell Inspiron N5110- which thanks to this drive is capable of a 2 second boot (from the windows logo appearing to the desktop loading), and antivirus programs, VPN and other usually boot-intensive applications are an instant load and transfer speeds between drives, never seen anything like it in a system I have owned - in fact it even beats the write speeds of apple's new "faster" SSDs in their 2015 MBP 15" refresh.
 
One thing to note, just because Linux doesn't handle TRIM very well (or so it seems by your post), doesn't mean other OSes aren't better at it. This is the problem with Open Source programming - often it is done by people living in their parents' garage or basement. Nothing wrong with that though as there are some truly bright people out there, however same isn't said for everybody. Companies such as Apple however have reputation for only employing people who are a true asset - take all their acquisitions as an example - only the chiefs usually get kept because they have the most to offer.

Uhm… no. These are real bugs in the firmware, unrelated to Linux. And saying that people that write code for Linux are not a true asset is an insult to everyone that writes code for Linux.
 
The good news is that the far majority of USB and Thunderbolt enclosures do not forward TRIM commands to the drives.

Do you have a reference you can direct me to regarding Thunderbolt and TRIM? I was under the impression one of the advantages of TB was that it did handle TRIM well.
 
(...Either way, the benefits of TRIM on OS X are largely placebo)

That's the counterintuitive part I love the most. People demand TRIM because they believe it increases performance in all cases (as opposed to only the Windows/NTFS case) while, in actuality, TRIM can incur a severe performance penalty on operating systems that have extremely small (if any) speed hit when not using TRIM like on OS X and Linux.

can you tell us where you have this information from?
i heard that from some people, while others have a completely different opinion.
the matter of trim or not trim seems to fall within the realm of faith... does it?
but then why should apple implement it now (and use it for their own drives!) if its largely placeo?
 
Uhm… no. These are real bugs in the firmware, unrelated to Linux. And saying that people that write code for Linux are not a true asset is an insult to everyone that writes code for Linux.

full ACK! saying that linux doesn't handle trim well is total BS. linux just uses the latest possibilities/functions available. and it looks like a lot of the SSDs on the marked don't work as intended/advertised...
 
Yay for TRIM. Using an 840 EVO with the latest firmware on my 2011 17" MacBook Pro with no issues. TRIM enabler has been working fine for me since day one, minus the one time I got a gray screen in the first Yosemite beta.
 
can you tell us where you have this information from?
i heard that from some people, while others have a completely different opinion.
the matter of trim or not trim seems to fall within the realm of faith... does it?
but then why should apple implement it now (and use it for their own drives!) if its largely placeo?

Reference for the NTFS thing? Just comparing SSD benchmarks on Windows when using TRIM and not using TRIM vs the gaps on Mac OS X when using TRIM and not using TRIM.

On Windows, there is a spectacular difference between the two. On Mac OS X, the speed difference is almost small enough to be a statistical error (especially when benchmarks show the read speed going faster when TRIM is enabled, which shouldn't be possible). But with newer drives that use far better garbage collection, the gap on both operating systems starts to narrow. I would not be surprised at all if future SSDs completely drop support for TRIM (and TRIM is a major layer violation, the filesystem should not have to worry about the intimate details of the physical storage medium!)

Samsung was actually going to try to implement NTFS-aware SSD firmware (firmware that scans the NTFS structures on disk) to negate the issues with not having TRIM but it caused way too much data loss in testing and they dropped it.

It's funny but the various methods an OS uses to prevent defragmentation also helps to prevent the massive speed drop without TRIM as an older SSD gets full even though fragmentation itself is not a worry on SSDs. Namely, if you are copying or writing a huge file, asking the SSD to zero-fill the range of logical blocks you are about to write to up front can kick off a GC session to move data around at the beginning. But if you don't ask for that range up front, then the SSD will have to do multiple read-erase-modify-write cycles for each physical block during the write, leading to that huge performance hit Windows saw in the past. (Again, newer SSDs can mitigate this a bit by having a sufficiently large cache that is used before writing the to SSD)

Examples of the type of operations that depend on disk space allocation: Downloading files from the internets, downloading torrents. Or just about anything that is a stream of data with a known size.

As to why Apple's even bothering to implement TRIM? Because people keep demanding it be there and actually go out of their way to decrease the security of Mac OS X to enable something that has no material benefit. Even if Apple blacklisted known-bad firmware, people would still try to workaround it. While synthetic benchmarks like AJA can show a small difference in speed on a drive that is full, a person using Mac OS X is never going be in a situation where it impacts their workflow. It's just not worth the risk to enable TRIM.

Personally I think Apple should just show "TRIM enabled" in System Profiler and in IOKit even if TRIM commands are never sent. That would make everyone happy.
 
  • Like
Reactions: Cisco_Kid
asking the SSD to zero-fill the range of logical blocks you are about to write to up front can kick off a GC session to move data around at the beginning.
And will also result in the disk being completely occupied while this is done, and it will move around a significant amount of obsolete data.

Had the drive been TRIMed, there would already be a much larger amount of pre-zeroed blocks available .
 
Last edited:
Another reason to hold off updating from Mavericks until El Cap is released (unless 10.10.4 actually includes the ability to enable TRIM)

The TRIM issue is the only reason why my Late 2012 iMac is still on Mavericks and will remain so until I can have third party support.

I also submitted a request for it via the feedback tool, so I assume enough people have brought it up that it has become something they wanted to address. You know how they like to talk about how many people have adopted the latest version of the OS during a keynote!
 
  • Like
Reactions: Badagri
  1. You cannot use the age of an account to determine experience with a system.
  2. I forgot my password for my older account.
You can see that all the Samsung SSDs beginning with 8 are blacklisted from having TRIM support in Linux due to data loss bugs. Googling for these kinds of problems is difficult because they are usually only found in forums or other places that have a robots.txt file denying Google from indexing the site.

The fact you haven't seen data loss issues with your Samsung 840 Pro could mean a number of things.

  1. The data is corrupted but you haven't noticed the problem yet.
  2. TRIM commands are not actually being issued to the drive.
  3. You are extremely lucky and are pressing your luck by continuing to have TRIM enabled.
The best you can hope for in your case is that #2 is happening in your situation.

(And you can of course see other people mentioning non-TRIM related bugs on the Samsung 840 drives in this very thread)

I also have a 840 Pro and haven't had any issues with it at all with TRIM enabled. Read / write benchmarks haven't suffered any performance degradation so far.

Question - If the data on the drive is corrupt, and I use Time Machine to backup to external disk, does that mean that the data on backup disk is also corrupt? So if my SSD were to crash, and I restored a new SSD from a TM backup, would my new drive also contain the same corrupt data that plagued the original SSD?
 
Question - If the data on the drive is corrupt, and I use Time Machine to backup to external disk, does that mean that the data on backup disk is also corrupt? So if my SSD were to crash, and I restored a new SSD from a TM backup, would my new drive also contain the same corrupt data that plagued the original SSD?

If you backed up corrupted data, you will restore corrupted data. If you know the time when the corruption began, you can restore to a point before the corruption (provided you have the pre-corruption system/data backed up).
 
  • Like
Reactions: tgd85 and Weaselboy
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.