Samsung Acknowledges and Fixes Bug On 840 EVO SSDs
Lucas123 writes: Samsung has issued a firmware fix for a bug on its popular 840 EVO triple-level cell SSD. The bug apparently slows read performance tremendously for any data more than a month old that has not been moved around on the NAND. Samsung said in a statement that the read problems occurred on its 2.5-in 840 EVO SSDs and 840 EVO mSATA drives because of an error in the flash management software algorithm. Some users on technical blog sites, such as Overclock.net, say the problem extends beyond the EVO line. They also questioned whether the firmware upgrade was a true fix or if it just covers up the bug by moving data around the SSD.
So are they going to fix the Samsung SM841 SSD or are we just screwed because we bought Dell?
It will be better to purchase from an owner who is a good farmer and a good builder.
This gets me wondering what brand of SSDs is best these days. I've read a lot of good about Intel brand drives, but wonder what is decent these days.
This is almost certainly a firmware bug with their read disturb compensation. At least they're owning up to it - but wow.
"Dos version for MAC, Linux users ... Will be released on end of Oct."
http://www.samsung.com/global/business/semiconductor/samsungssd/downloads.html?CID=AFL-hq-mul-0813-11000279/
Let me guess - the source for that firmware patch is stored on a Samsung EVO 840 disk?
Ah, crap, I just bought 1 too; which means none of data is more than a month old. At least they're giving away a fix. Gee, more mess to deal with... :(
More technical detail as to what is going on.
http://www.anandtech.com/show/...
Glad I haven't upgraded from my Samsung 830 256GB from 2 years ago this month. Still chugging along like a champ with no degradation.
Couldn't write a proper wear levelling algorithm if their life depended on it.
First the MAG4FA/KYL00M/VYL00M data corruption bug that affected the Galaxy Nexus - https://android.googlesource.c...
Then (actually BEFORE it, Google found it during Galaxy Nexus development but Samsung kept it hush-hush - but it became a public issue much later) - the infamous Samsung Superbrick fiasco (If you fired a secure erase command at the chip, it had a chance of permanently corrupting the wear leveller data to the point where the chip's onboard controller would crash until you power cycled it any time you accessed that region of flash). - https://git.kernel.org/cgit/li...
Then pre-release 840 PRO devices suffer from the SAME DAMN BUG SAMSUNG HAD BEEN AWARE OF FOR OVER A YEAR - http://www.anandtech.com/show/... - While this only affected review devices, the fact that this was a known bug since before the release of the Galaxy Nexus (a year earlier) is inexcusable.
Then there was the Galaxy S3 "Sudden Death Syndrome" issue in late 2013... - https://github.com/omnirom/and...
Then there were a few other issues - http://wiki.cyanogenmod.org/w/...
Now this...
retrorocket.o not found, launch anyway?
I've used or installed a dozen or more 840 SSDs and never had a problem with any of them, including the 470 model I'm using now.
Is what's being fixed a widespread problem or a corner case of specific uses?
There will be a bootable DOS disk image for Mac and Linux users. It's supposed to be released late October, according to the download page:
https://www.samsung.com/global...
Eat the rich.
Am I totally screwed?
Yes, unless you can wait 'tii the end of October for the LInux version (which may be a DOS executable). Alternatively, presumably the firmware upgrade can be done by moving the drive to a Windows box without doing the "Performance Restoration".
Don't have Windows here. Would be nice if they had a firmware patch that could run on Linux.
What implications are there for encrypted LVMs? Is it advisable to run such a setup on an SSD anyway or will it break some internal algorithms?
Also Intel-only. At least on my AMD board it tells me that "I have to disable 3rd party drivers", this despite absolutely current AMD AHCI drivers. Somebody really messed up at Samsung.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
VNAND run at current 1X node levels should provide 32x the capacity for similar cost. Instead Samsung is using their tech to release 4X node level SSDs with similar capacity but double the cost of 1X node level 2D NAND. When the heck are we going to have some competitors come in with their own VNAND tech and bottom out the SSD market? They should even be able to achieve greater cost per byte effectiveness than HDDs.
You can use a bootable DOS disk/USB stick to update the firmware.
The 'performance restoration' part just rewrites all the data on the disk. You can get the same effect by backing up the disk, formatting, and copying all the data back.
(Brief summary: The problem makes data slower to read as it sits there. The firmware fix prevents that from recurring, rewriting the data fixes it on already-existing data. There's no data loss associated with this, just speed.)
In my case, based on hdparm -t on xubuntu and centos, the difference between a properly aligned Samsung EVO and an improperly aligned Samsung EVO is 510 MB/sec and 182 MB/sec respectively
http://cillian.wordpress.com/2... has some good info on setting up Samsung EVO properly on linux
My 512GB 830 series heats up like the CPU does. The 500GB traditional 7200rpm drive next to it stays relatively cool. I thought SSD were the future of the storage, not a flipping burn/fire hazard!
short answer: yes.
I would not trust their 'fix' if they actually work at the filesystem level.
you'd think this was a sector based issue. you'd think!
even if there is a dos bootable for this, unless it understands ext2/3/4 (and maybe others; jfs, reiser, xfs) then linux guys ARE screwed by this.
--
"It is now safe to switch off your computer."
250GB EVO running for a year now, i never noticed slowdows using it as my daily SO drive. I guess its because the frequently accessed files aren't affected by this bug, i would have to run a complete drive read test to find out.
I did a test with a tool in one of the links and got the same results as other people.
http://i.imgur.com/1xomFsK.png
See how the graph goes down as age of files increases.
After running the tool to update the firmware and "optimize" the drive the graph is very different.
http://i.imgur.com/37m1bkn.png
Now i have to check again in a couple of months. I could run a full defrag and get the same result since all files would've been moved.
Managed it with going back to the msahci driver (select update -> available on this machine).
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
> Blah. I'm running Linux with ext4 on my Samsung SSD 840 EVO 250GB (EXT0BB6Q).
> Am I totally screwed?
Not totally as long as your chipset is supported, but almost.
All you need to do is extract actual SSD firmware upgrade file from Windows executable, then create freedos bootable USB stick, copy DOS updater files extracted from older Samsung DOS updater download and add those new SSD firmware from new Windows updater to your custom upgrade USB stick. After you have managed to upgrade SSD firmware boot system using some live linux and do non-destructive badblocks read+rewrite scan over entire SSD.
I wonder if I can "fix" my RAID 5 system with a one disk at a time approach. Pull a drive. Use Linux to zero the drive. Use Windows to build the requisite NTFS partition to prevent complaints. Run the update. Rezero the partition information. And finally reinstall the drive in the RAID and let the RAID rebuild. Lather, rinse, repeat three more times for the other disks.
Of course, methinks I'll take a complete disk image backup of the RAID just in case.
Any thoughts regarding this approach? Is there anything simpler that can be done?
{^_^}
Apparently (according to the website) it only affects sectors that have been written to exactly once since the SSD was new, and never changed afterwards. Those sectors still work, but are read more slowly. Any sector that has had data written to it more than once, is not affected. So I guess I'm OK since I wiped and installed my OS several times, using encryption, so I imagine all sectors must have had stuff written to them more than once.
You can get the same effect by backing up the disk, formatting, and copying all the data back.
Or much simpler (on a Mac, anyway), turn full disk encryption off and then on again. You can even continue to work while it's rewriting the entire disk.