Samsung's SSD 840 Read Performance Degradation Explained

An anonymous reader writes with a link to TechSpot's explanation of the reason behind the performance degradation noticed by many purchasers of certain models of Samsung SSD (the 840 and 840 EVO), and an evaluation of the firmware updates that the firm has released to address is. From the piece, a mixed but positive opinion of the second and latest of these firmware releases: "It’s not an elegant fix, and it’s also a fix that will degrade the lifetime of the NAND since the total numbers of writes it’s meant to withstand is limited. But as we have witnessed in Tech Report’s extensive durability test there is a ton of headroom in how NAND is rated, so in my opinion this is not a problem. Heck, the Samsung 840 even outlasted two MLC drives. As of writing, the new firmware has only been released for the 2.5” model of the SSD 840 EVO, so users of the 840 EVO mSATA model still have to be patient. It should also be noted that the new firmware does not seem to work well with the TRIM implementation in Linux, as this user shared how file system corruption occurs if discard is enabled."

Comments

toy anyway

[dshk]

It has no power loss protection, so now it could lose data much faster. It should be good for worthless data but that is all. I am not sure if it has at least small capacitors, the half-assed power loss mitigation technique which does not protect new flushed data, but at least prevents the loss of old, unrelated data.

Re:toy anyway

[tlhIngan]

It has no power loss protection, so now it could lose data much faster. It should be good for worthless data but that is all. I am not sure if it has at least small capacitors, the half-assed power loss mitigation technique which does not protect new flushed data, but at least prevents the loss of old, unrelated data.

You don't need power protection if you take precautions and design your system around the fact that power can be removed at any time.

Some SSDs cheaped out and didn't have power protection AND used features that requires it (usually to get better performance - obviously if you're not worried about power dropping abruptly, you can avoid writing code to protect against it). It's no surprise those SSDs corrupted data liberally because their translation tables got corrupted.

But there are plenty of SSDs that aren't concerned with performance. In fact, if you're on SATA, performance is no longer important as they're all maxing out the SATA bus. If you're wondering why they all seem to be at 540MB/sec read and writes, that's because SATA is now the bottleneck. So now you can spend lots of time working on power-fail-safe firmware - because if you're stuck at 540MB/sec, it doesn't matter what performance tweaks you do because you're stuck there. If you can do 1GB/sec internally, and power safe code loses 40% of that, you do it. 1GB/sec is wasted on SATA, but you can save a few bucks by not needing power backup parts. 40% loss brings you down to only 600MB/sec, which is faster than SATA still.

It's why next gen SSDs are going PCIe - 540MB/sec is nothing compared to 1.5GB/sec you can find on Apple's machines.

Power fail is nice to have, but given everything's limited by SATA more than anything else, it's currently optional. For PCIe SSDs, you'd expect power fail components because you need performance.

Ironically, the faster it is, the less you need since you just need to dump your tables to storage ASAP, and if you're able to do 1.5GB/sec writes, and your tables are 500MB in size, you only need power for half a second. While if your media speeds was only 500MB/sec, you';d need power for a whole second.