Slashdot Mirror
Endurance Experiment Writes One Petabyte To Six Consumer SSDs
crookedvulture (1866146) writes "Last year, we kicked off an SSD endurance experiment to see how much data could be written to six consumer drives. One petabyte later, half of them are still going. Their performance hasn't really suffered, either. The casualties slowed down a little toward the very end, and they died in different ways. The Intel 335 Series and Kingston HyperX 3K provided plenty of warning of their imminent demise, though both still ended up completely unresponsive at the very end. The Samsung 840 Series, which uses more fragile TLC NAND, perished unexpectedly. It also suffered a rash of cell failures and multiple bouts of uncorrectable errors during its life. While the sample size is far too small to draw any definitive conclusions, all six SSDs exceeded their rated lifespans by hundreds of terabytes. The fact that all of them wrote over 700TB is a testament to the endurance of modern SSDs."
Yes, they are sooo reliable, every single SDD I've bought has been dead within 3 months.
Odd - I've got 5 and all are well. 1 Intel, 2 Samsung and 1 Critical. I guess I'm lucky and you are not.
Place nail here >+
Why? The failure modes are completely different (and yes there are quite a few reports around on this subject..)
SSDs have a write capacity limitation due to write/erase cycle limitations (they also have serious long term data retention issues).
Mechanical drives tend to be more limited by seek actuations, head reloads, etc. The surfaces dont really have a problem write erase/write cycles.
Nether are particularly good for long term storage at todays densities. Tape is MUCH better.
Rejoice then, you still have 75 SSDs!
Get free satoshi (Bitcoin) and Dogecoins
hey thanks for sharing your anecdotal experience as if it carries any weight whatsoever compared to actual controlled experiments and statistics.
for comparison, I've owned 8 and no failures yet. I have a raid0 array of SSDs upstairs that has been working flawlessly since 2008. an aberration maybe. anecdotal evidence works like that.
i could live a little longer in this prison
has anyone tried this with platter drives?
A few years ago, Google published a study of hard disk failures. Failures were not correlated with how much data was written or read. Failures were correlated with the amount of time the disk was spun up, so you should idle a drive not in active use. Failures were negatively correlated with temperature: drives kept cooler were MORE likely to fail.
that reminds me ... I should do a backup ....
i could live a little longer in this prison
Good luck with that. This experiment has been running since Aug 20, 2013 and running almost continuously at that. Even the heaviest consumer/prosumer work load would have trouble reaching the amount of data written in this experiment.
the problem with tape is by the time you can retrieve the data you're interested in, it no longer matters.
i could live a little longer in this prison
Not that much higher for streaming reads and writes, the new Seagate 6TB can do 220MB/s @128KB streaming reads or writes. That works out to ~19TB/day so it would only take around 2 months to hit 1PB.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
You might want to do a bit of math before making such a statement. 700TB is a very large amount of data. And in order to do that in a week, would require quite a bit of data transfer bandwidth. To wit:
700,000,000,000,000 / 7 days = 100,000,000,000,000 / 24 hours = 4,166,666,666,666 / 3600 seconds = 1,157,407,407 bytes per second.
Do you really write 1.157GB/second every second for a week? And if so, what data interface are you using? I'd really like to know since SATA 3.0 can only handle 600MB/second. Perhaps you're using SATA 3.2 which does have the required speed?
Now in an environment using multiple drives, you can get to the 700TB mark much more rapidly with much lower per drive bandwidth. But then again, that's not the test criteria. They are testing how much endurance individual SSDs have.
"I've got 5 and all are well. 1 Intel, 2 Samsung and 1 Critical. "
That apparently doesn't prevent you from dropping bits, though. 1+2+1=4.
"National Security is the chief cause of national insecurity." - Celine's First Law
The 8MB problem is an Intel firmware bug (older, non-Sandforce controllers). If you don't care about your data, ATA "security erase" can make it usable again. I think I used the DOS-based hdderase, and after a few problems it went through. Intel's DOS-based flash idiotically ignores the SSD because it identifies itself as "BAD_CTX"...
Yes, they are sooo reliable, every single SDD I've bought has been dead within 3 months.
A happy OCZ customer, I take it?
I don't recall the brand of the fourth, got distracted and forgot to edit. But I knew someone would have fun pointing it out, so it would be rude for me to deny you the pleasure. So - yeah - I dropped a bit. :D
Place nail here >+
While ShanghaiBill apparently struggles with the English language, the phase "you should idle a drive not in active use" means the drive will spin up fewer times. You should disable spin down and leave the drive idling, not on standby.
You'll reduce the number of head load/unloads.
You'll reduce peak current consumption of the spindle motor.
The drive will stay at a more stable temperature.
Failures were correlated with the amount of time the disk was spun up, so you should idle a drive not in active use.
That makes no logical sense unless the statement is missing a "not" somewhere, or unless you WANT failures.
You're reading the sentence wrong. You're reading it as "Times the disk was spun up".
What they mean is the total amount of time the disk has spent spinning over its lifetime.
upon the advice of my lawyer, i have no sig at this time
Which will also spread around the writes. If you're writing a 4TB video across 10 disks, that's only 410GB to each, so you only get that much endurance used up.
Amen to this, I STUPIDLY bought a REFURBISHED OCZ drive which, coincidentally failed shortly after OCZ announced bankrupcy. The other drive I bought was a Corsair that, like it's OCZ bretheren died three weeks after put into service. The speed is wonderful but the life is pathetic. Despite this, I have a Kingston and a Samsung which are both going strong so I can confidently state that HALF OF ALL SSDs FAIL AFTER THREE WEEKS, THE OTHER RUN FOREVER!
Perhaps I need to work on my sample set and my over-use of capital letters.
"I don't recall the brand of the fourth"
:-)
There you go again.
"National Security is the chief cause of national insecurity." - Celine's First Law
There was also a very interesting endurance test done on extremesystems.org. Very impressive stuff. I don't yet own an SSD, but I'll continue to consider buying one! Maybe next Black Friday. Just waiting for the right deal.
Quite an experience to live in fear, isn't it? That's what it is to be a slave.
Tape actually has pretty high transfer rates. Its seek times are what sucks, but if you're doing a dump of tape you arent doing any seeking at all.
That's a heck of a lot of data, and certainly more than most folks will write in the lifetimes of their drives.
Continued write cycling [...]
That's just ridiculous. Since when the reliability is measured in how many petabytes can be written?
Spinning disks can be forced into inefficient patterns, speeding up the wear on mechanics.
SSDs can be easily forced to do a whole erase/write cycle just by writing single bytes into the wrong sector.
There is no need to waste bus bandwidth with a petabyte of data.
The problem was never the amount of the information.
The problem was always the IO pattern which might accelerate the wear of the the media.
All hope abandon ye who enter here.
We seem to have the beginning of a trend here - AC's don't have very good luck with SSD's.
Try logging in and see if that changes your outlook.
Faster! Faster! Faster would be better!
That's curious. Almost all of the drive failures I've seen can be attributed to head damage from repeated parking prior to spin-down, whereas all the drives that I've kept spinning continuously have kept working essentially forever. And drives left spun down too long had a tendency to refuse to spin up.
I've had exactly one drive that had problems from spinning too much, and that was just an acoustic failure (I had the drive replaced because it was too darn noisy). With that said, that was an older, pre-fluid-bearing drive. I've never experienced even a partial bearing failure with newer drives.
It seems odd that their conclusions recommended precisely the opposite of what I've seen work in practice. I realize that the plural of anecdote is not data, and that my sample size is much smaller than Google's sample size, so it is possible that the failures I've seen are a fluke, but the differences are so striking that it leads me to suspect other differences. For example, Google might be using enterprise-class drives that lack a park ramp....
Check out my sci-fi/humor trilogy at PatriotsBooks.
See for yourself.
Why didn't you just refer to the LHC web page and imply that you are writing at that same data rate to a single SSD...it would have exactly the same value as an argument.
If seeking does wear a drive, then using an SSD for files that generates lots of seeks will not only greatly speed up the computer, but also extend the life of HDDs relegated to storing big files.
How is 700TB "endurance"? I copy near a TB of data from Backups at work almost daily. So 1-2 years (if that) is "endurance"? Screw that! Sounds more like modern SSD's suck hard and aren't designed to last past 1-2 years of work. I'll stick with traditional HD's until they figure out DRAM drives that don't need batteries or constant power.
How large is your backup filesystem(s)? This was 700TB written to a 250gb drive. If you're copying "near a TB of data from Backups ... almost daily", then I'm betting you have many many TB of storage in the backup pool... so divide that by 250gb and multiple that by 700TB and that's the endurance the SSD's would have. However, even then it doesn't really apply... your backups are not likely to be rewriting a lot of sectors (ex. deduplication, if used, means few files are actually written). You also said you copied FROM backups, so those are just reads (I'm presuming those are going out to multiple clients).
In any case, the 700TB "endurance" figure is still acurate, even if you consider that fragile - it's a level of endurance under a specific use case.
FWIW, for a backup system, I'd also stick with spinning disks (or tape) for now and well into the foreseeable future. Throughput and IOPs are not very important to backup storage, and you'll get way more GB/dollar from HDD's.
Stopping and starting a drive is also a moment where you can break/wear down a drive. This can be explained by the fact that heads rest on platters (unless in parked position) when the platters are not spinning at the right speed. Also, because a drive that is being spun down will cool down and warm up again when being spun up. These temperature fluctuations will be of influence on the drive reliability. The most plausible explanation I can come up with is that temperature shifts will make parts inside the drive align differently, possibly permanently changing alignment enough for head-misalignment to occur.
I was promised a flying car. Where is my flying car?
A few years ago, Google published a study of hard disk failures. Failures were not correlated with how much data was written or read. Failures were correlated with the amount of time the disk was spun up, so you should idle a drive not in active use. Failures were negatively correlated with temperature: drives kept cooler were MORE likely to fail.
Actually the paper says that the Google guys approximated power-on hours with a notion of age, which I assume was approximated by a knowledge of either the manufacture date of the delivery date. From the paper, annualized failure rate (AFR) is somewhat correlated with age, but not necessarily strongly enough to predict probability of failure. Even with their large drive population, the paper points out that the drive model mix is not consistent over time and therefore, not much can be made of the apparently weak correlation between AFR and age, which could be perhaps be more greatly influenced by drive model.
The negative correlation with very cold temperatures is interesting but hard to understand without further analysis. Perhaps some drive models didn't handle fly height adjustments well at low temperatures. It's hard to figure out without more data. It should also be pointed out the temperatures were obtained via SMART, and the SMART standard doesn't mandate how temperature is reported. So, different manufacturers could report temperatures in different ways, i.e., different locations (which can easily vary by up to 30 degrees C), different aggregation methods (time windows, sampling frequency), etc. So, the aggregate data is probably not as useful as the data per drive model.
If you read the article (I know this is Slashdot) they explain that MWI is an Intel-only SMART attribute. They use different SMART attributes for the Kingston and Samsung drives.
Intel:
Kingston:
Samsung:
No, I logged in and I've still got Outlook 2007.
Hail Eris, full of mischief...
E pluribus sanguinem
The problem is that there are two ways for the drive to park the heads. (FYI - ALL spinning rust drives these days park the heads on power down). One of them is more violent than the other.
There is the normal ATA spin down command which the OS issues to stop the drive, which causes a nice orderly movement of the heads to the parking area (or unloads the heads). On a drive datasheet, I saw they were rated for about 50,000 cycles of this.
Then there's the emergency poweroff park, which uses the rotational momentum of the platters to provide power to the voice coils that slam the heads against the parking area (basically the power is funnelled straight into the voice coils). It needs to move ASAP as the platters are slowing down and the air cushion that keeps the heads from hitting the platters is dissipating the slower the platters move. So by dumping the back EMF into the voice coil, the heads are forced into the parking area while there's still enough movement to keep the heads away from the platter. This is so much more violent on the heads that a drive can easily be rated for 10,000 cycles of this or so (under "emergency park").
Modern OSes typically send a spindown command prior to shutdown because it allows an orderly flushing of the caches into non-volatile storage, the heads can seek to the parking area in a controlled fashion and then the platters can spin down without worrying that the heads may contact the platters.
You can easily tell which is the case - a normal spindown is very quiet (in a quiet room you can hear it), while an emergency park is heard by a loud clunk from the drive followed by a dying whine.
Of course, there are bugs, and some OSes excessively unload/load the heads that could easily exceed the 50,000 number in the span of months (I think one distribution of Linux suffered from this due to a BIOS-Linux interaction).
As for those complaining about the unusual nature of the test - well, it's stressing the weakest aspect of each storage medium. Reading/writing massive amounts of data doesn't really impact the drive longevity, but mechanical motion does - keeping a drive spinning wears the bearings, while spinning up and down wears the motor, and emergency parks puts extreme stress on the entire mechanical arm. On an SSD, none of those really do anything - but writing massive amounts of data DOES wear it out.
So the tests aren't directly comparable, but they address the weakest part of each storage medium - spinning rust wears mechanically, while SSDs wear electronically.
The other thing SSDs can suffer from is the emergency power off - because to achieve the speed they cache the entire FTL tables in RAM and then lazy-sync it to the storage medium. On power down, they need to flush the dirty changes to media. Some SSDs use capacitor banks to do this, others use journalled writes to allow safe updates.
Either way, FTL table corruption is the #1 reason why SSDs die today - rarely do they actually die from the media actually wearing out. Luckily, a ATA SECURITY_ERASE command fixes that (in most cases) since it reinitializes the tables but generally keeps all the wear indicators as they were. And this happens almost always on powerdown.