Intel Confirms Data Corruption Bug, Halts New SSDs 137
CWmike writes "Intel has confirmed that its new consumer-class X25-M and X18-M solid state-disk drives (SSDs) suffer from data corruption issues and said it has pulled back shipments to resellers. The X25-M (2.5-inch) and X18-M (1.8-inch) SSDs are based on a joint venture with Micron and used that company's 34-nanometer lithography technology. That process allows for a denser, higher capacity product that brings with it a lower price tag than Intel's previous offerings, which were based on 50-nanometer lithography technology. Intel says the data corruption problem occurs only if a user sets up a BIOS password on the 34-nanometer SSD, then disables or changes the password and reboots the computer. When that happens, the SSD becomes inoperable and the data on it is irretrievable. This is not the first time Intel's X25-M and X18-M SSDs have suffered from firmware bugs. The company's first generation of drives suffered from fragmentation issues resulting in performance degradation over time. Intel issued a firmware upgrade as a fix."
Ugh... summary.... (Score:3, Informative)
"The company's first generation of drives suffered from fragmentation issues resulting in performance degradation over time."
The performance degradation in the Intel X-25 is not because of a "firmware bug". All SSD's will suffer performance degradation whether or not their writing/wear leveling algorithms have been updated via firmware.
Re:Ugh... summary.... (Score:5, Informative)
Re:BIOS password on a disk? (Score:4, Informative)
Re:Ugh... summary.... (Score:4, Informative)
The performance degradation in the Intel X-25 is not because of a "firmware bug".
Bugs can cause slowdowns, too
Though it's highly regarded, Intel's X25-M SSD had a firmware bug that adjusted the priorities of random and sequential writes, leading to a major fragmentation problem that dropped throughput dramatically. The issue was originally uncovered by PC Perspective after two months of testing. Those tests showed that write speeds dropped from 80MB/sec. to 30MB/sec. over time, and read speeds dropped from 250MB/sec. to 60MB/sec. for some large block writes.
https://www.techworld.com.au/article/302571/ssd_performance_--_slowdown_inevitable?pp=3 [techworld.com.au]
Before firmware update
the result suggested a write speed of 30 MB/sec.
http://pcper.com/article.php?aid=691&type=expert&pid=3 [pcper.com]
After firmware update
After composing myself, I did the same file copy I had tried earlier. 76 MB/sec.
http://pcper.com/article.php?aid=691&type=expert&pid=4 [pcper.com]
Not a firmware bug?
Re:Test before you ship (Score:5, Informative)
As a professional FW tester, I can say 1) firmware can be tested easier than the hardware verification the parent is talking about, and 2) Parent is confusing HW verification with firmware verification. Don't confuse HW verification with Firmware, and don't confuse Software testing with hardware verification. They are vastly different than each other, and have their own set of tools and methods (try sitting through a STAR East or STAR West seminar as a FW tester - it is a total waste of time).
I can (and do) test firmware on buggy hardware all day long - its not an issue.
Non-destructive fw update coming + rave on G2 (Score:3, Informative)
Although this bug should have been caught faster it seems that it is possible to update the firmware without any data loss (fortunately I have put it in a laptop, power outages are no problem). I've looked at the Intel site and the flash utility seems to be simply bootable from CD - if this is the last bug I'll be a very happy punter indeed.
My 80 GB G2 SSD replaced a not too fast laptop drive. I'm now trying Linux, but I'll try Vista as well just for fun - I'll just write my 80 GB to an external drive using Gparted. These drives come highly recommended even if they would slow down to 50% of performance (which, it seems, they don't). I unzipped Eclipse to it and JavaDoc and I could see that the archiver that unzipped the .zip has some performance issues reading the index. It took longer than the unzipping and gunzipping and untarring (the Eclipse gunzipping/untarring took less than 2 seconds - yikes). The only thing faster is the tmpfs in RAM which I used to compile the OpenJDK in on my "workstation". Starting Eclipse takes now less time on my laptop than on my workstation even though it got twice as few cycles.
Re:Ugh... summary.... (Score:3, Informative)
"Although Intel acknowledged that all of its SSDs will suffer from reduced performance because of significant fragmentation, the type of write levels needed to reproduce PC Perspective's results aren't likely for everyday users, whether they're running Windows and Apple's Mac OS X. Even so, it still released the firmware upgrade to slow fragmentation."
At least it's not Seagate (Score:1, Informative)
Re:Ugh... summary.... (Score:3, Informative)
Unusually bad? More severe than necessary? Not really. Even with this supposed degradation, it was ages ahead of any and all competition. What was unusually bad was the complete lack of understanding from all reviewers who did not understand basic principles and the fundamental limitations of flash and yet rushed ahead with their articles. Those poor fools expected that the driver should behave like a regular HDD - they weren't prepared for the unavoidable deterioration in performance.
I expect they will be similarly surprised when some drives stop working, because Flash has a very limited number of rewrites. Wear leveling improves the situation, but it just postpones the inevitable. For example, if the driver us full to capacity and you start rewriting a single sector at full speed, you will get to the 10000 rewrite limit relatively quickly.
Re:Ugh... summary.... (Score:3, Informative)
Don't answer with generalities unless you have really thought about it. Wear-leveling is based on heuristics; since it cannot predict the future it is always possible to construct scenarios which will hit the worst case. And if it is theoretically possible, it will happen.
Imagine a simple case and go from there. Imagine a flash with 5 blocks total, 4 sectors per block. The logical capacity is 16 sectors; the extra block is over-provisioned for wear leveling, etc. Now, imagine that you have the 4 blocks neatly filled with occupied sectors and the 5-th block is erased.
What happens if you want to write to a random sector? The sector is written in the erased space in the 5th block and its physical position is updated in the map. If you repeat that operation 3 more times, the 5th block will get filled with 4 used sectors, and each of the other 4 blocks will have one invalid sector on the average. So far so good.
What happens if you want to rewrite a random sector now, though? Tough luck. You need to erase a whole block, pack all valid sectors in it, and write the modified sector.
From now on you get one erase per sector write. Not only that, but you get 3 additional writes. That is called write amplification and is unavoidable in the worst case.
Now, tell me, how will wear leveling have helped this? Wear leveling works well only well there is plenty of free space. And even then it is possible to construct artificial bad scenarios.
Re:I find this disturbing (Score:3, Informative)
Aircraft (F-16 among others) flight control firmware has been updated by reprogramming UVPROMs for many years.
What took them so long to report this? (Score:5, Informative)
Welcome to 2 weeks ago:
http://www.pcper.com/comments.php?nid=7544 [pcper.com]
Allyn Malventano
Storage Editor, PC Perspective
Re:Typical redditor (Score:4, Informative)
Functional simulations will only catch #1.
Re:I find this disturbing (Score:3, Informative)