Slashdot Mirror
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."
I think the concern is that this would somehow dramatically increase the probability of data loss caused by powering the drive even while it appears to be inactive. After all, it randomly rewrites flash blocks. However, in practice, this should not be an issue.
Presumably, their firmware never erases and rewrites a flash page in place. And presumably it does not write the log entry that causes the drive to look for those blocks in the new location until after the page has been fully written. Assuming they do, in fact, follow those rules, then a power interruption during a block clone should never result in loss of any data, because the data still exists in the old page, which will not be invalidated in favor of the replacement copy until that replacement copy is fully written. If they aren't doing that, then they are incompetent, and their drives should never be trusted with cat pictures, much less valuable data.
Check out my sci-fi/humor trilogy at PatriotsBooks.
We have a bunch of shared build PCs with 840 Evo SSDs in them and we noticed strange problems when we build off the SSD (over say, the HDD).
Basically what would happen after a little while (a month), all of a sudden during the build the entire system would practically lock up - all the cores are pegged at 99% system time, and system responsiveness collapses - it can literally be minutes for the system to respond. It makes a little headway, but compilation speed drops (since 99% of every core is spent in the kernel). It's completely fine off the hard drive, and if it wasn't for this loss in speed, the SSD would be faster (right now because it pauses a few minutes every 15 or so, the HDD is faster).
It's completely unusual - I did try to analyze the kernel, which appeared to have all the cores tied up in ext4 spinlocks. Not sure if it's a result of the tables being slow and blocking or what.
It happens under high load - I normally set the build at 12 threaded builds (8 cores!). Thought at first it was Linux collapsing under the weight of the build, but it's actually the SSD. Building off hard drive on the system system is no problem at all.