TRIM on Samsung SSD might be broken?

tomvos

macrumors 6502
Original poster
Jul 7, 2005
341
108
In the Nexus.
There's a blog entry about a possible problem with some Samsung SSDs when using trim.

https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/

Up to now this problem was only spotted under Linux and was not confirmed by anybody else yet. Nevertheless, I thought it might be of interest to one or another here. Since Samsung SSDs have been recommended a lot in the past.
Perhaps it's a prudent move to disable trim — if you enabled it — for Samsung SSDs for the time being.
 

IowaLynn

macrumors 65816
Feb 22, 2015
1,304
287
I don't see EVO 850 listed or mentioned as a problem, and yes it could be isolated to enterprise Samsung SSDs, Linux kernel, and even the type of use and such. Samsung 'consumer" grade SSD have been torture tested to 500TB of writes without significant loss of cells or problems from what I have read.

I do know of folks that did not use TRIM and were having real problems with OS X though.
 

crjackson2134

macrumors 601
Mar 6, 2013
4,490
1,624
Charlotte, NC
There's a blog entry about a possible problem with some Samsung SSDs when using trim.

https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/

Up to now this problem was only spotted under Linux and was not confirmed by anybody else yet. Nevertheless, I thought it might be of interest to one or another here. Since Samsung SSDs have been recommended a lot in the past.
Perhaps it's a prudent move to disable trim — if you enabled it — for Samsung SSDs for the time being.
Very interesting read... Thanks for posting this.
 

lowendlinux

Contributor
Sep 24, 2014
5,155
6,309
North Country (way upstate NY)
I don't see EVO 850 listed or mentioned as a problem, and yes it could be isolated to enterprise Samsung SSDs, Linux kernel, and even the type of use and such. Samsung 'consumer" grade SSD have been torture tested to 500TB of writes without significant loss of cells or problems from what I have read.

I do know of folks that did not use TRIM and were having real problems with OS X though.


I have an 850 Evo and it's not passing the trim command




If it was there's be a line in the middle

 

bradl

macrumors 601
Jun 16, 2008
4,006
11,823
One thing to note on this, and it was also in a link to an Ubuntu user's email to Samsung about this:

https://bugs.launchpad.net/ubuntu/+source/fstrim/+bug/1449005/comments/53

Followup: My email to Samsung clearly and succinctly stated that there is a bug in their firmware, where it wrongly reports "I support NCQ TRIM!" but it really doesn't, and that they introduced the bug recently. I said nothing about Linux.

Their mentally retarded response: "Dear Customer,

Thank you for contacting Samsung Support regarding your concerns and inquiries. We apologize for any inconvenience this may be causing you. Since Linux is open source, Samsung does not support the OS. All we can tell you is that you can disable Queued TRIM in Linux. Linux will then start using Sequential Trim, which is similar to how Windows does TRIM. Newer versions of Linux kernels blacklist the drive so that Queued TRIM automatically is disabled.

Thank you again for contacting Samsung Support and have a good day.

DM

CS20204"

In other words: "Our product is broken, so just tell the OS not to use the broken feature and hey presto you're a winner! Now stop bugging us with your Loonixes and stuff."

Can we try to get press attention on this? Random corruption caused by regular TRIM operation is almost as serious as the 840 Evo's data retention issue.
In looking at the blacklist, I noticed that the recent SSD I purchased from Samsung isn't on it (I bought the 850 EVO MZ-75E500B/AM 500GB), and was going to throw it into my windows box. I'm a bit hesitant now.

But the issue with this is related to using Queued TRIM, which is an option in Linux, versus Sequential TRIM, which is what is used in Windows. The key here is to find out what type of TRIM OS X is using.

BL.
 

bradl

macrumors 601
Jun 16, 2008
4,006
11,823
Caught this in the El Cap thread:

Edit: This post has a lot of visibility, so I'd also like to point your attention to an earlier post of mine which gives you safe TRIM in Yosemite 10.10.3 and up:



The following is the original post from before the edit, and has nothing to do with the above edit:

----------------------------------------------------

Geez... there's a lot of combined issues in that article...

The first issue is the queued TRIM implementation in Linux. It is the only operating system that tries to send FPDMA QUEUED TRIM (a new SATA II extension of NCQ, and therefore also called NCQ TRIM). The latest Samsung firmwares mistakenly set word 77 bit 6 to 1 in the ATA IDENTIFY flags, which tells the OS that they support FPDMA QUEUED operations, when they actually don't. If you try to send a FPDMA QUEUED TRIM, the latest Samsung drives spectacularly overwrite random data with zeroes. The Linux kernel now blacklists those drives from trying to use FPDMA QUEUED TRIM, since they're misbehaving with that command. The Samsung engineers are aware of it since the issue first surfaced a year ago, but a fix is not yet ready.

So if you've got a modern Samsung drive, it's important that your OS uses regular sequential TRIM. Linux is the only OS that uses queued. All versions of OS X (even El Capitan) and Windows (latest) still use sequential TRIM, and will continue to do so for the foreseeable future.

Next up... the article is actually about a bug in the Linux kernel's sequential (non-queued) TRIM implementation.

You see... It's not just SSD firmwares that sometimes implement TRIM badly. The OS can do it wrong too, if it sends out incorrect TRIM commands that tell the SSD to delete data that's actually in use. You need the OS filesystem driver to understand the filesystem at a deep level so that it knows exactly how to properly TRIM it, and it also needs to be aware of what data is on the drive and what data is in the memory-buffered filesystem (which may be out of sync with what's on the drive), so that it knows exactly what data it will tell the SSD to delete. It's a very complex science and it even took Windows a while to get it right due to peculiarities in the NTFS filesystem. In the linked article's case, Linux is the culprit. They're talking to Linux kernel devs to get it fixed.

Since OS X and Windows use sequential TRIM, the followup questions become:
* A) Does my drive implement sequential TRIM properly?
* B) Does the OS implement sequential TRIM properly?

For A, the answer is YES for all modern drives. But NO for *old* drives such as early SandForce controllers. *THAT* is why Apple displays the warning saying that you're enabling TRIM at your own peril. It's also the reason why Apple only allowed TRIM on their own drives initially; because back when they first implemented TRIM in OS X 10.6.8 (July of 2011), a lot of popular drives had buggy TRIM implementations - and it's better to have a slow untrimmed drive than a corrupt drive.

For B, we need to find out whether the OS sends out correct TRIM commands and doesn't send out anything that would tell the drive to delete valid data. To test this, I coded a benchmark that first writes a 50 GB verification-file (a very large file, covering a lot of SSD surface area, and whose contents can be verified to be intact later), and it then writes and deletes/TRIMS over 1000 gigabytes of data, and then pauses to let the drive perform its TRIM and garbage collection, to be sure that all the TRIM commands have been carried out. The test was executed several times on a Samsung 850 PRO SSD (same one used in the article you guys linked to), on OS X Yosemite and OS X El Capitan.

Every single bit of the 50 GB test file stayed intact, thus proving:
* A) Yes, the Samsung 850 PRO with latest firmware implements old-school sequential TRIM properly.
* B) Yes, OS X (even El Capitan) uses *sequential* TRIM and has a proper TRIM implementation that *doesn't* tell the drive to delete random valid data.

So as long as your SSD properly implements sequential TRIM (and all modern ones pretty much do, since TRIM is default in Windows and all drives want to support Windows), then you'll have zero issues with enabling TRIM in *any* version of OS X.

And do we need TRIM? Yes. The SATA TRIM command was invented to solve an extremely important need: It's the *only* way for an OS to tell an SSD to free up space from deleted files. Without TRIM, the SSD will think that *all* blocks are in use until the OS tries to overwrite them again. If all blocks are marked as in use, the SSD is literally *physically full*, and in that state it will be extremely difficult for the SSD's garbage collection to try to passively free up a bunch of empty space for new writes to take place. So all further writes will first go into the SSD's on-board buffer (that's fast), but then they'll sit there for a long time as the SSD reads, merges and re-writes data (that's extremely slow). A lack of TRIM also causes write amplification, as the SSD's garbage collection shuffles around all blocks of dead/old data from deleted files that the SSD still thinks are in use and thinks must be preserved. TRIM is the only command that can let an OS tell an SSD that the data from a deleted file is safe to delete during garbage collection. If the drive had been properly TRIM'd, the SSD would have known that most of the space is actually free, and its garbage collection would be allowed to free up those blocks in the background so that they're ready for new writes. Garbage collection is basically a process that does two things: Erase TRIM'd blocks (the primary source of freeing up space on the disk for new writes), and erase overwritten blocks that have been invalidated by new data (that's only responsible for freeing up a *tiny* amount of the storage space on an SSD). So garbage collection without TRIM is like a runner with one leg. It works (kinda), but it's crippled.

Now relax, don't panic, and remember to always carry a towel.

This is worth the read, and should allay any fears about TRIM on OS X, especially for El Capitan and Windows. They use Sequential TRIM.

BL.
 

iBuildMacs

macrumors member
Dec 29, 2014
32
3
TRIM works fine on The Samsung 850. However, there are some chipsets / interfaces that cause the TRIM on the 850 to not work. For example, the external OWC On-The-Go FW/USB 3.0 enclosure does not allow TRIM on the 850, but works fine with other brand SSDs.