Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

haralds

macrumors 68040
Original poster
Jan 3, 2014
3,041
1,283
Silicon Valley, CA
Note: this has been resolved not to be an issue!

I just lost my 5TB Fusion drive based on a Corsair M500 (CT960) that had been working great until the 10.10.4 upgrade. While moving blocks from/to SSD, the system totally corrupted.

My hypothesis is that while earlier versions were using Sequential Trim, Apple might have switched. Some Corsair and I believe Samsung drive fail with Queued Trim.

Of rouse, this is independent of whether you use Trim Enabler of the new native command.

Caveat emptor! I am now staring at a 30plus hours TimeMachine restore....
 
Last edited:
This isn't what I was looking for but it may be helpful to you, I'll keep searching.

@mikeboss: Don’t worry about RosynaKeller. I read that conversation a day or two ago and he/she is the WORST kind of *MORON*: The kind who is an advanced computer user who knows the *names* of everything, and has a *general* idea of how computers work, but then starts extrapolating/misinterpreting and then passing off their *madness* as gospel. This is why they say that “a little knowledge is a dangerous thing”. That person is clueless about TRIM. He/she is dumb enough that I *almost* registered at MacRumors to clear up the ********, but I decided it wasn’t worth my time, and that other people would call the person out on most of it – and they did. And besides, I don’t care if the general population is misinformed about something; let them be.

There’s no race condition. An example of a race condition would be if the queue wasn’t processed in the correct order, such as if the following queue was sent: “Delete/trim block 102, Write to block 102″ and the write took place BEFORE the delete, thus deleting the newly written data. That is *NOT* what is going on, though! *All* SATA commands, whether sequential OR queued, are processed in the *exact* order they are received. There has never been, and never will be, any race conditions.

The initial *sequential* TRIM corruption (when TRIM was introduced) was because of misimplemented controllers that deleted random blocks instead of the desired block. It can now be assumed that all *modern* manufacturers have solved that issue by now, but I wrote this test tool just to be completely sure.

The *queued* TRIM corruption is because of misimplemented controllers that delete random blocks instead of the desired block. In the case of Samsung, the corruption is *spectacular*. Send a *single* queued TRIM and you’ll lose half of your data. If OS X had used queued TRIM, you would not have had a “Hash okay” on the 50 GB test file, I can assure you of that.
icon_wink.gif


Lastly: Apple’s warning about enabling TRIM is because older drives are a minefield of poorly implemented sequential TRIM, especially SandForce – which is why I wrote this tool to give people peace of mind.

PS: I am working with Samsung’s firmware department to fix the queued TRIM in a future firmware update. It really only matters for Linux since it’s the only OS using the new queued TRIM spec, but it’s a good thing if OS X or Windows ever switches over too.

PPS: I am signing out of this forum, since everything I came here to discuss is done now.
icon_wink.gif

@mikeboss: Thanks a lot for that test. It was more useful than you might have thought! Because you just proved that OS X El Capitan *still* uses SEQUENTIAL TRIM (just like Yosemite and earlier, and just like Windows).

That’s a very important discovery. Because that means that so far only Linux uses QUEUED (NCQ) TRIM.

The modern “Queued (NCQ) TRIM” was recently created by the SATA standard as an even faster way to TRIM data, but it’s the new “dog” in the house and the situation with it is just as bad as back when the original TRIM launched: Loads of modern drives are misimplemented and destroy data wildly if you try using it. All Samsung 840s and 850s with the latest firmware (yours is, and mine too) advertise that they support queued TRIM but they actually don’t, and if you try sending a queued TRIM, all drive data is destroyed as a result. And you can google “queued trim corruption” to find loads of other drives like Crucial etc equally malfunction during queued TRIM.

So your El Capitan test is fantastic news. It means OS X is still doing Sequential TRIM for the foreseeable future, and that’s a great thing for all of us!

And of course, as for the Samsung drives you and I have tested, we’ve now proven that sequential TRIM works perfectly for those two very popular drives, so that’s good news too.
icon_wink.gif
 
This isn't what I was looking for but it may be helpful to you, I'll keep searching.

I am waiting for an assured test on the latest 10.10.4 drivers. The failure behavior absolutely looks like a trim failure.

The fact the El Capitan does not have it in the current beta build does not mean the drivers for 10.10.4 release were not changed. BTW, I ran the beta builds of 10.10.4 without problems.

Caveat emptor!
 
I am waiting for an assured test on the latest 10.10.4 drivers. The failure behavior absolutely looks like a trim failure.

The fact the El Capitan does not have it in the current beta build does not mean the drivers for 10.10.4 release were not changed. BTW, I ran the beta builds of 10.10.4 without problems.

Caveat emptor!

There is a script to test for that already, but I hesitate to post it since it's not mine, and it's not intended for use by novice users. Create an account at clindori's website and you can find the script. 10.10.4 has already been tested and passed the muster, it uses sequential trim. It works fine for me and everyone else I know. If you don't want to use it that's fine too, you likely won't see much difference for quite some time anyway.

BTW, the script is intended for use on an empty drive...
 
Last edited:
Here is why this was the most likely hypothesis:
- No problem with drive temps and SMART. Drive health has been great.
- No console errors, the OS thought everything was fine
- Rapidly expanding drive "file permission" errors starting with frequently used files in ~/Library as they were moved.

To the system everything looked fine. But as it regrouped the Fusion content, the Corsair started mucking up sector assignments - permanently.

Still could be something else, but given the timing and the known history, this looked like a logical hypothesis.

We will know in 30+ hours, whether there is another issue.

The system has been error and crash free for months.
 
We will know in 30+ hours, whether there is another issue.

Not necessarily, I've had spinners (obviously not fusion drives) present similar problems when moving data, but there is no trim to blame there. Reformatting and refreshing everything seems to fix the problem forever. It's possible the problem was related to the fusion implementation rather than trim. Also, since there is a rotational drive in the mix, it's that much harder to pin down. It could be related to trim, but even if it is, that doesn't mean that OS X is using queued trim commands instead of sequential.

I can see that you are a hard sell, so I won't bother you with this anymore.

This seems to be a logic Cause and Effect fallacy -
assuming that the effect is related to a cause because the events occur together.
  1. Example: When the rooster crows, the sun rises. Therefore, the rooster causes the sun to rise.
  2. Example: When the fuel light goes on in my car, I soon run out of gas. Therefore, the fuel light causes my car to run out of gas.
 
Not necessarily, I've had spinners (obviously not fusion drives) present similar problems when moving data, but there is no trim to blame there. Reformatting and refreshing everything seems to fix the problem forever. It's possible the problem was related to the fusion implementation rather than trim. Also, since there is a rotational drive in the mix, it's that much harder to pin down. It could be related to trim, but even if it is, that doesn't mean that OS X is using queued trim commands instead of sequential.

I can see that you are a hard sell, so I won't bother you with this anymore.

This seems to be a logic Cause and Effect fallacy -
assuming that the effect is related to a cause because the events occur together.
  1. Example: When the rooster crows, the sun rises. Therefore, the rooster causes the sun to rise.
  2. Example: When the fuel light goes on in my car, I soon run out of gas. Therefore, the fuel light causes my car to run out of gas.
Thanks. That is why I called it a hypothesis. It has not advanced yet to a full theory
The system has worked in this configuration for well over a year up and through 10.10.4 beta (which did not have the trimforce command, I checked.)
"Correlation is no causation" is another name for this and one of my pet peeves, too.
 
how was your Fusion drive constructed? was it natively created when installed OS X or through a command/hack? im wondering if it was through a command/hack and trimforce enabled it jolted that.

if you have an SSD+HDD OS X will auto create a fusion drive for you, i'd TRIM The SSD first then have OSX recreate your fusion, then reinstall and restore and see if that goes smoother
 
I just lost my 5TB Fusion drive based on a Corsair M500 (CT960) that had been working great until the 10.10.4 upgrade. While moving blocks from/to SSD, the system totally corrupted.

My hypothesis is that while earlier versions were using Sequential Trim, Apple might have switched. Some Corsair and I believe Samsung drive fail with Queued Trim.

Of rouse, this is independent of whether you use Trim Enabler of the new native command.

Caveat emptor! I am now staring at a 30plus hours TimeMachine restore....

I also think that something probably went wrong with your fusion setup.
Maybe the trim change just triggered the fault.
Also perhaps there is something with the specific restrictions of the MacPro's SATA2 bandwidth and your fusion drive.

It seems that they still use the sequential method for TRIM.

We have enabled trim in a Mac Pro 3,1 under 10.10.4 with two SSDs, a Crucial M500 and a Samsung evo 840 and everything seems fine, till now.
 
Last edited:
  • Like
Reactions: haralds
I also think that something probably went wrong with your fusion setup.
Maybe the trim change just triggered the fault.
Also perhaps there is something with the specific restrictions of the MacPro's SATA2 bandwidth and your fusion drive.

It seems that they still use the sequential method for TRIM.

We have enabled trim in a Mac Pro 3,1 under 10.10.4 with two SSDs, a Crucial M500 and a Samsung evo 840 and everything seems fine, till now.

Cool. Keep us posted. I hope, I am wrong...
 
sounds like you need to enable trim, then recreate your fusion drive.
Actually, the sequence of events does not matter, since they are unrelated.

But I recreated my system and backed it up once more. Based on the lack of evidence that the OS X trim mode changed, I enabled it again after running some benchmarks. I will keep you posted on whether I will run into issues again.

BTW, there is no "hack" involved in creating a Fusion Drive. Apple simply has not (yet) provided a high level tool. It simply involves diskutil to create a coreStorage drive out of two or more drives with the SSD first and then creating a logical jhfs+ volume on this logical drive. That's it!

BTW, I really could not see a difference in performance, but testing it just was too much of an itch...
 
I just
I just lost my 5TB Fusion drive based on a Corsair M500 (CT960) that had been working great until the 10.10.4 upgrade. While moving blocks from/to SSD, the system totally corrupted.

My hypothesis is that while earlier versions were using Sequential Trim, Apple might have switched. Some Corsair and I believe Samsung drive fail with Queued Trim.

Of course, this is independent of whether you use Trim Enabler of the new native command.

Caveat emptor! I am now staring at a 30plus hours TimeMachine restore....
I just was pointed to what looks like a knowledgable post here:
https://forums.macrumors.com/thread...ved-performance.1891936/page-10#post-21469307

I have since used the native command to enable trim, all seems to be fine so far.
 
Actually, the sequence of events does not matter, since they are unrelated.

But I recreated my system and backed it up once more. Based on the lack of evidence that the OS X trim mode changed, I enabled it again after running some benchmarks. I will keep you posted on whether I will run into issues again.

BTW, there is no "hack" involved in creating a Fusion Drive. Apple simply has not (yet) provided a high level tool. It simply involves diskutil to create a coreStorage drive out of two or more drives with the SSD first and then creating a logical jhfs+ volume on this logical drive. That's it!

BTW, I really could not see a difference in performance, but testing it just was too much of an itch...

I was going to say the same thing but in a more curt way, I'm glad you responded.
 
I just lost my 5TB Fusion drive based on a Corsair M500 (CT960) that had been working great until the 10.10.4 upgrade. While moving blocks from/to SSD, the system totally corrupted.

My hypothesis is that while earlier versions were using Sequential Trim, Apple might have switched. Some Corsair and I believe Samsung drive fail with Queued Trim.

Of rouse, this is independent of whether you use Trim Enabler of the new native command.

Caveat emptor! I am now staring at a 30plus hours TimeMachine restore....

Luckily, this seems to be a non-issue. MacCNN did some extensive testing and all looks good so far:
http://www.macnn.com/articles/15/07...noted.in.testing.the.popular.ssd.line.129472/
 
My M500 Crucial on 10.10.4 so far has had no issues for several weeks. What makes you think Apple changed from sequential to queued for their trim commands? Everything I've read has indicated only some Linux distributions enabled queued trim.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.