Slashdot Mirror
SSD Annual Failure Rates Around 1.5%, HDDs About 5%
Lucas123 writes "On the news that Linus Torvalds's SSD went belly up while he was coding the 3.12 kernel, Computerworld took a closer look at SSDs and their failure rates. While Torvalds didn't specify the SSD manufacturer in his blog, he did write in a 2008 blog that he'd purchased an 80GB Intel SSD — likely the X25, which has become something of an industry standard for SSD reliability. While they may have no mechanical parts, making them preferable for mobile use, there are many factors that go into an SSD being reliable. For example, a NAND die, the SSD controller, capacitors, or other passive components can — and do — slowly wear out or fail entirely. As an investigation into SSD reliability performed by Tom's Hardware noted: 'We know that SSDs still fail.... All it takes is 10 minutes of flipping through customer reviews on Newegg's listings.' Yet, according to IHS, client SSD annual failure rates under warranty tend to be around 1.5%, while HDDs are near 5%. So SSDs not only outperform, but on average outlast spinning disks."
An intel apologist supporting intel? Shocking!
"client SSD annual failure rates under warranty tend to be around 1.5%, while HDDs are near 5%"
So they are less likely to fail early in their life.
NOT:
"So an SSDs not only outperforms, but on average outlast spinning disk."
This is completely unsubstantiated by the evidence provided.
So you need to multiply the failure rate of the SSD by as many SSDs as it would take to equal the storage of the disc. Do you want the storage rate per arbitrary device size, or rate of failure per data stored?
Yet, according to IHS, client SSD annual failure rates under warranty tend to be around 1.5%, while HDDs are near 5%. So an SSDs not only outperforms, but on average outlast spinning disk.
What about annual failure rates outside of warranty?
If you have a new Apple notebook it does not matter what the rate is - you can not replace them.
Lose the SSD and you have lost the Retina.
errr
1.5% of a 4TB SSD that sells for USD$29,000 is roughly 60 GB = $425.
Alright, I'll do the math....
9ms average access times on a 7200RPM spinning drive == ~100 IOPS.
High-end SSD: 100K IOPS.
Yes, a thousand times the number of disk accesses. If you're really a developer, you'll see your compile times cut by a factor of 5-10 (depending on how much CPU power you have to spare). Things load from disk like magic.
You don't buy SSDs for the raw capacity, you buy them for the *fast* access times. Period.
Is 4TB representative? Or are you just putting more spin on this story?
Gary Dunn
Open Slate Project
5 years should be mandatory by law. If you can't support your drive for 5 years, you shouldn't be allowed to manufacture hard drives at all.
I don't understand this new trend in making new hard drives with only 1-2 years warranty. The same goes for SSD.
9ms average access times on a 7200RPM spinning drive == ~100 IOPS.
High-end SSD: 100K IOPS.
The SSD that most consumers are using are neither high end nor have such IOPS ratings.
Fail Troll is FAIL
That under warranty less SSDs fail doesn't mean they outlast HDDs... If warranty is 1 year, and all SSDs fail in 1.5 years, yet hard drives usually fail only in 3 years, hard drives are still better off.
In other news, Laxori666 was too lazy to RTFA and is hoping someone will chime in. He is tired and drowsy and so he will blame it on that when in fact, he would have done the same regardless - except perhaps without this addendum as such honesty usually requires some sort of altered state of consciousness.
Ba-doomp-CRASH!
Yet another reason to never buy Mac.
You're absolutely right.
That's why we lease them for work;
READY.
PRINT ""+-0
While catastrophic drive failures make headlines what's more likely to happen during the useful service life of both HDDs and SSDs are unrecoverable media/bit errors and these may ruin your day as much as a catastrophic error. If you look at the bit error rate of any contemporary HDD and compare it to its capacity you'll come to a startling conclusion - an unrecoverable read error is rated to occur once every 2 to 5 times the full capacity of the drive is read. SSDs have about the same unrecoverable read error rate.
Yet, according to IHS, client SSD annual failure rates under warranty tend to be around 1.5%, while HDDs are near 5%. So an SSDs not only outperforms, but on average outlast spinning disk."
The unknown in the equation is the length of the warranty periods for the drives used in the comparison.
Anyone who isnt using a SSD by now for at least their boot drive is stuck in the past.
It's the single best upgrade you can make anymore.
Either way stop the fucking articles about it.
Leave them with their warm feelings for spinning rust full of multi gigs of stuff they never touch.
They'll wise up eventually. Or not.
Either way it won't hurt you any. Enjoy your speedy pc and laugh at the rusties if you must.
> as a developer, I have no use for SSD in my desktop system.
Do you compile code?
SSDs are for booting. RAM disks are for compiling, and hdd is for long term storage.
When our name is on the back of your car, we're behind you all the way!
*shrug* As a developer, installing an SSD paid for itself in time saved due to waiting on disk within three months.
Seriously, git is instantaneous, greps and compiles are ludicrously fast, etc,, etc, etc. I mean, unless your rate is like 10USD/hr, you owe it to yourself and your clients to install a decently-sized decently-fast SSD in all of your dev boxes.
5% of a 4TB HDD that sells for USD$200 is roughly 200 GB = $10.
1.5% of a 4TB HDD that sells for USD$29,000 is roughly 60 GB = $425.
You mean 5% of the space size in GB is that.
Your math is wrong, because you are misinterpreting the statistics. A 1.5% SSD failure rate, with a small number of disks, does not mean that "1.5% of the capacity" fails; if you purchased N 4TB SSD "that sells for 29k"; on average N*1.5% Of those entire SSD drives fail; and if you purchased N 4 TB HDDs that sell for $200, N*5% of those entire HDDs fail.
Due to I/O constraints; when you use HDDs, you don't get to use all your total space, before performance degrades to unacceptable levels, and you have to buy more HDDs; furthermore, all those extra HDDs consume a lot more power than SSDs. The $/IOP is not attractive for HDDs: the vast majority of computer users do not need 4TB HDDs; and will use 100 to 150GB TOPS.
Therefore: SSDs look a lot more attractive, when you discount, or forget the existence of the portion of the capacity that the user cannot use due to performance constraints, or will not use -- due to not needing the space.
Last I checked; you cannot go to Amazon, Newegg or your local supermarket and buy a 200GB hard drive for $10 It is not an option; the least cost new HDD you can pick up is about 60 bucks. However, you definitely can go to Newegg, and buy a new 150GB SSD for about $250.
Also, the Crucial M500 1TB SSD is $600. 4 times that is $2400, not $30,000.
4TBs are for archival purposes, where the hard drive will be powered off most of the time, anyways. The failure rate of 3 TB and 4 TB HDDs is probably much higher than the 5% average, due to the tighter mechnical tolerances and higher density encoding methods required. I believe the 5% figure applies to 1.5TB disks.
Actually, you'd be surprised. The Samsung 840 EVO, a low-cost consumer drive (the high-end is the 840 Pro) that gets down to $0.70/GB, can hit 90K IOPS read on every model, and 90K IOPS write on 500GB models and up.
Sure, older or ultra-cheap drives won't hit that (my new Chronos doesn't get there), but rounding to the nearest order of magnitude will get you 100K IOPS even on medium-end consumer drives.
OCZ's failure rates are higher than the rest of the industry's by an order of magnitude. Also, earlier SandForce drives have reliability problems because the firmware was written by paranoid loons who were deathly afraid of reverse-engineering and the drive goes into irrecoverable 'panic mode' when any abnormality of any kind is sensed. I think that newer SandForces (post-LSI acquisition), especially Intel's, are less likely to do this, but the original failures still taint the brand with the stigma of flakiness.
If you stick with Samsung, Intel, and SanDisk, you should be fine. Stay away from OCZ at all costs, and be skeptical of any SandForce drive not made by Intel.
What are the warantee periods? Are SSDs shorter. Is it the same usage scenario -- for example using the SSD for swap?
What do the failure curves look like?
I suspect for HD's it's a gaussian and for SSD's it's a skew normal distrubution with the scew leaning towards the end. Meaning a large amount of SSD fail past a certain. time while many HD still work? Have we even seen enough SSD's in the wild to see that failure yet?
More to the point, you can buy 4 4TB HDDs for $800 and setup a RAID1 and get a lot of the same read performance as an SDD while having heavy redundancy. Yes, you don't get the same level of gains for writes nor do a lot of systems support 4HDs readily (not enough physical space to place them) and there's the issue of power consumption. But if there's a 5% of failure with one HD, then presuming there's no relationship to the drives (ie, you don't just buy a bunch of drives from the same company which were all from the same batch production), then you'd expect a very low probability that all the drives would fail (something like 0.000625%). Besides that, you could very trivially buy multiple extra HDs for backups and still be way cheaper all around.
Eurohacker European paranoia, gun rights, and h
I got my 1st ssd this spring, it was awesome and fast, for 3 weeks.
What a coinicidence... so was mine. Still is, as a matter of fact. Oh, and so is the one in my laptop.
When our name is on the back of your car, we're behind you all the way!
I've heard several people state that they've bought SSD drives that just would not work when they got them home and they had to do an exchange. Do these statistics include those returns or only ones that failed in service?
A while back Joel Spolsky (joel on software) tried switching to an SSD and compared his compile times to his old HDD. The result: no difference. Apparently, the disk access isn't the slow part of the compilation process. The bottleneck in compiling seems to be the processor speed.
After "doing the math" a mixture works - cheap small SSD for system files and a pile of spinning disks with ZFS to hold stuff. Of course on MS Windows with the C: drive nonsense still hanging about a mixed system is a bit more difficult and may mean a bigger and more expensive SSD for those programs that will only work on the system drive.
I've got an EeePC with an SSD. Bought back in 2008. Still runs fine.
Have gnu, will travel.
another story on /.
...
a TRULY dead ssd is impacting the linux kernel release.
one in Linus's server.
bad timing, to try to pump bad statistics.
there are lies
damn lies
then there are statics
better to go with the lies
and hire better tech aware ad men
You might want to factor in that SSD's often have longer warranties than HDD's these days.
OCZ's SSD's are 3-year while Intel SSD's are 5-year. HDD's manufacturers reduced their warranties from 3,4, or 5 year to 1, 2, or 3 year in 2011.
I'm not saying that thats the situation of the data in the study, but it could be. 5% on an average 2 year warranty vs 1.5% on an average 4 year warranty, well that is quite a significant difference.
"His name was James Damore."
Now for the useful information. How many of the failed SSD's were they able to recover data? I suspect not many.
Only the State obtains its revenue by coercion. - Murray Rothbard
Wrong stat.
Yes, things to break, but its important HOW they break. HDDs have very 'nice' failure modes. You can recover bits from the platters as long as you do not put one in MRI machine or a fire. SSDs just DISAPPEAR from the system with data and encryption keys to that data and NO ONE including manufacturer can do recovery (they can put flash chips in reader and read encrypted bytes, but encryption keys were in the controller that just died).
How about another one: Warning before failure rate? Again 90% HDD, 1% SSD.
Do you know how many SSDs survive running out of spare sectors? Again about 1% :) 99% just die without going into read only mode.
Who logs in to gdm? Not I, said the duck.
> as a developer, I have no use for SSD in my desktop system.
Do you compile code?
With a 32 GB RAM, why do you thing compilation would be relevant for the SSD or HDD choice?
Questions raise, answers kill. Raise questions to stay alive.
I think it's a good question whether warranties are unequal.
I think it's a bad assumption that they are slanted to SSDs (for instance, the demand seems more likely to be there for SSD warranties given the reputation). It might be true but it's not obviously true.
Or... you know.... actually put some RAM into your developer machine.
Questions raise, answers kill. Raise questions to stay alive.
Everyone's already jumped on you on this one, but I still have to chime in and say holy crap are you ever wrong if you think a SSD is not worth every dime right now.
You don't need *everything* to be on SSD, just the commonly-used data; your system, binaries, etc. I have a 120GB Intel 330 series SSD (though in hindsight I'd rather have gone with something ~250GB and 2TB of normal spinning disk, plus a 7TB server. The system, my home directory (minus downloads directory), and my main games are on the SSD, the rest of my games are on a 1.5TB 7200 RPM disk, and downloads get an old 500GB disk. My machine spends more time in POST than the entire rest of the boot process, browsers launch instantly, IDEs take half a second, games practically skip their own loading screens, etc.
Unless you place no value on your time, in any interactively-operated machine where you can have multiple storage drives a SSD is a no-brainer. Laptops where a second disk is challenging or impossible it entirely depends on your mobile storage needs, but the reduction of moving parts and performance/battery improvements are a strong argument in favor of them.
I used to get high on life, but I developed a tolerance. Now I need something stronger.
So, if 5% of hard drives are failing in the first year of warranty, then the other ones have to last 180 years on average in order to meet the MTBF specifications of 1.5 million hours that hard drive makers claims. Because surely they wouldn't lie to us.
If you are not allowed to question your government then the government has answered your question.
Even the 840 Pro isn't that expensive actually, just ordered one today.
http://www.newegg.com/Product/Product.aspx?Item=N82E16820147193
- Michael T. Babcock (Yes, I blog)
Wait, you are basing the improvements in compile times on one guy's anecdotal results? Well, here's another: when I switched to an SSD at work my compile times were cut by more than half. It was an huge difference in compile time ie. productivity.
It all depends on your codebase and tools, really. He was probably compiling a relatively small codebase, and for all we know his methodology sucked so a lot of it was in the RAM cache. I can tell you for a fact that a clean build on a large code base was drastically improved.
For any reasonable code size, the data's all cached in memory already from you editing and saving the files in question.
- Michael T. Babcock (Yes, I blog)
No he's doing the math right -- At an annual failure rate of 1%, you need to replace 1% of your total capacity every year. With an annualized failure rate of 5%, you need to replace 5% of that capacity overall. The averaging is done because over time, it works out, just like insurance. Sure, on any given year *if* a drive fails, you have to pay for the whole thing, but that's not how one accounts for such failures.
- Michael T. Babcock (Yes, I blog)
Statistics are wonderful things, if you choose the right one you can make any case you want. I want to know more about the warrentees. I want to hear about the nature of the issues. Recoverable errors vs complete death. Infant mortality vs just wear.
More to the point, you can buy 4 4TB HDDs for $800 and setup a RAID1 and get a lot of the same read performance as an SDD while having heavy redundancy.
Where by "a lot of", you mean less than 1% of, right?
Typical IOPS on a 7200 RPM HDD is around 80. Typical IOPS on a garden variety SSD is 80,000. We'll be generous and assume linear speedup for the four HDDs, which gives us 320 IOPS, or 0.4% of the performance of a single SSD.
Game! - Where the stick is mightier than the sword!
How often does a developer need to do a clean build? If your build flow is set up right, not very often. Especially not often when the developer is in the critical code/compile/fix-compile-errors or compile/run/debug/fix loops which are where the compile times are important. There are even build flows/tools that let you not ever do a clean build, by storing versioned object files. And if your codebase is large enough, hopefully you're using dynamic linking which means that the link step isn't too long either.
Why on earth do you need 4TB "as a developer"?
And it's absurd to claim that SSDs aren't useful over HDDs just because HDDs are more cost effective by space. HDDs are also more cost effective by space than RAM - so why not just minimize your RAM and create a huge swap space?
I upgraded to an SSD recently and compile times didn't really change at all, which was surprising. Boot times, application load times, system responsiveness etc however are massively improved. At least on my setup (Xeon E31270, Windows 7, Visual Studio), compile times aren't particularly IO limited.
According to Research from Segate, a hybrid drive needs just 8gb of NAND to achive %95 performance of a a NAND drive in a typical business environment "During the five days of study, the average amount of data read by machines in a business environment stood at 19.48GB. Out of this amount, just 9.59GB was unique; the rest consisted of duplicate reads" Of course this is not exactly a large scale study, but it was presented in a industry workshop so its not just fabricated marketing material either. http://www.techweekeurope.co.uk/news/seagate-hybrid-drives-dont-need-more-than-8gb-of-nand-124069
Since benchmarking software is useless for gauging the effect of caching, It would be interesting to see a similar study done on typical usage scenarios for a home machine.
Yet, on a laptop with a 128GB SDD, I've got ~95GB free. Why would I want to buy a huge HDD, if I've got more than enough with a tiny SDD?
Differente people have different needs, and, the point is, for those who want reliability for a brand new disk, SSDs are the way to go.
Fairly large codebase here, ~4 minute compile times, C++ with Visual Studio. Compile times were unaffected by the SSD upgrade. Searching code, however, massive speed improvement and paid itself off with productivity improvements after about a month.
And everything you said reinforces my statement, "It all depends on your codebase and tools, really" :) Not everyone (in fact, probably very few) get to pick all of the tools and libs that they use...
I had to do a clean build today, actually. And it was unavoidable. I upgraded my PS4 SDK, and not doing a clean build when your entire libc/SDK/etc changes is practically a guarantee of random impossible to track down errors in your app. Due to quirks of the existing system, that particular build was almost 5x faster on my machine vs. a coworker's using a slower, non-SSD machine. 1/2 hour saved times 2-3 clean builds easily pays for the disk already.
I've been running multiple partitions/drives on Windows for years and haven't encountered a sizeable app that I'd want to put on a different drive that wouldn't let me.
There's one thing I'd like to mention about SSDs that you don't take into account. You can't use all of the space on an SSD either without performance degradation. I'm a SSD user myself, but it's just as true of SSDs as HDDs that you don't want to actually fill it past a certain point.
Great. Thanks for, like so many other people in this thread, pulling out a near meaningless benchmark figure*. As others point out, you might see 1000x the IOPS but real world results are more on the order of at most 5-10x speedup (a look at some of Tom's Hardwares HDD vs SDD seems to confirm it with adding music to WMP on HDD and on SDD and Gaming on HDD and on SDD). Why is that? Obviously because most applications and activities don't involve randomly accessing 4K files/sectors scattered all over the storage device. File systems are heavily designed to avoid fragmentation and most file accesses are linear and of considerable enough size that actual streaming performance is more critical. Hell, ReiserFS (both in synethic and real benchmarks) has shown that just having the file system actually intelligently deal with smaller files (NTFS does this with the MFT, AFAIK) nets most of the same benefits.
So the other point would be something about whether four HDDs would see a linear performance increase and see the 3x increase and start to approach SDD territory. Honestly, I actually doubt it. And I'm certain in some circumstances SDD would still heavily blow away what even a large stack of HDDs in RAID1 could do. But in most real world circumstances, the difference would be pretty damn negligible, except probably noticing how slow big file copying can be.
*Yea, I know this isn't an actually meaningless figure. It gives you some idea of just how much better random access to files will be. And if you have a specific workload that deals with lots of non-cached random files or sectors in large files, I can certainly see some clear benefits to SDD. But, honestly, coupled with things like caching, lots of RAM in system now days, things like Superfetch, and having just limits on just much data can actually stream over SATA, SDD isn't worth it to me or a lot of people--but then most people aren't going to do RAID at all and SDDs main benefit would be the no-moving-parts and lower power usage for portables. If you're one of the exceptions and can afford the massive extra cost, good for you.
Eurohacker European paranoia, gun rights, and h
RAM disks are for initrds and initramfs images.
Research from Seagate says their hybrid drive only needs tiny ssd? Imagine that.
Help stamp out iliturcy.
Last year I bought a used 90GB Kingston V200 used off Craigslist. I am running my Linux installation right now off of it. At first I treated it with kid gloves and tweaked everything I knew how to tweak to reduce writes, including turned off swapping entirely-- with 16GB RAM I never touched the swapfile anyway-- reduced the swappiness system variable, etc. When I went from Mint 13 to 15 I only turned off the swapfile and it's still running like a champ, but a part of me still just doesn't trust the little darling. I decided to get a larger one to run my W7 installation on and bought an Intel 520-series 180GB one. It too has been rock solid reliable. I trust Intel more than Kingston and probably will take W7 off it and put on Linux the next time I upgrade my OS. Anyway, the gist of what I'm saying is, they've both done very well for me. I have no personal experience with OCZ but everything I've read says stay away. Samsung makes the drives that go in Macbooks, though I don't know if the 840 you can buy at retail is the exact same one as in the Apples. For anyone thinking of taking the SSD plunge, I say go ahead. I highly recommend Intel, but then I really don't boot to Windows that often these days so the the 520 gets *much* less use than my little Kingston. It's been a workhorse.
Hard drives typically have shorter warranties than SSDs. OCZ has a bad reputation for having reliability issues compared to other SSDs yet their warranties are 3-5 years. The typical Seagate and WD warranties are now 2 years.
... if i need to store x TB of data, i can set up a RAID1 mirror and have fault tolerance for way less than the cost of SSD based storage to hold it in a non-fault tolerant manner.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Industry damage control
Spectacularly poorly, in my experience, for the kinds of things I do.
Who cares? That's why you use them for your boot drive and not to store your porn collection.
^^ +1 insightful, for having correct priorities. I wish I had mod points today.
********* sig: If you don't like the law, get filthy stinking rich, and buy a better one.
C compiles very fast on modern computers. Fortran, I haven't any modern experience. C++ is spectacularly slow to compile if the code being compiled is at all sophisticated. And it's all compute. The drive light barely lights up for minutes at a time.
Then you're a shitty developer.
As a developer, switching to an SSD was the biggest improvement I've ever made to my workflow. My 2009 machine with an SSD out performs my 2013 i7 machine with a 6 disk raid 1+0 machine with 16GB of ram. (which now has an SSD in it as well)
The time savings of an SSD on source files and compiling is ridiculous.
My time is worth FAR more than an SSD, sorry yours isn't.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Visualizing Linus, on an old laptop in a hotel somewhere busily merging the kernel of the world's most popular OS. Probably in his jammies. How the world has turned.
Help stamp out iliturcy.
No, you are still in a universe in which you compile on a 386...
Tomorrow is another day...
...
Compiling is almost ALWAYS IO bound for a project of any size. Why do you think make -j 4 or make -j 8 makes a noticeable difference on even single core machines? Because the compiler spends most of its time waiting on disk IO, reading and writing all those intermediate files.
VisualStudio also supports parallel compilers for this exact same reason.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
And the thing to remember about all storage is that it will fail. If you have a single disk in a machine, and that machine is not backed up properly, then you will lose that data in the next 5 years.
It's hopeless. The rubes are mod'ing up GP, while parent is the one who is correct.
SSDs are for booting. RAM disks are for compiling, and hdd is for long term storage.
RAM disks are for compiling? how small are you projects?
It said "windows 98 or better" so I installed Linux
Idk about 4TB, but you can get a 1TB system for $635.
http://www.newegg.com/Product/Product.aspx?Item=N82E16820147251
Dude, you don't know what you're missing. I use both, HDDs are now my data drives for archives, and SSDs are my primary boot drives and the data I'm immediately working on. I'm glad I'm working on HDDs anymore.
Run a few dozen MS Windows systems with a variety of software instead of a single machine and you'll start finding them :( The biggest culprit in my case comes from Halliburton of all places and expects to put it's data files on C: as well, which is a pain when projects are a few hundred GB each. When you copy a project to another machine it has to be on exactly the same path, so big system drives are needed all round.
Even on Windows it's easy to move "My Documents" off of C:. "Program Files" is not the big barrier in most cases. FAT32 is long dead for system drives, and NTFS has symbolic links.
I question the 5 percent annual failure rate for hard drives. I haven't had 1 in 20 hard drives fail ever. That's at least a couple of magnitudes off the MTBF numbers.
$0.70/GB is very good for mid-range SSDs. 1.00/GB for top-range SSDs is affordable now, but the laws of diminishing returns still applies as it does with all other forms of newer technologies.
Life is not for the lazy.
Because the compiler spends most of its time waiting on disk IO, reading and writing all those intermediate files.
That's why smart people put any intermediate files in a RAM disk.
Depends on what they're developing, now, doesn't it? Maybe a huge database. Maybe video processing code. Heck, I'm not even primarily a developer and I currently have 19TB on my primary desktop and 32TB on two servers.
RAM disks are for compiling? how small are you projects?
How big are yours, if the generated files won't fit in a few gigabytes of RAM?
Talk about timing. I'm right now recovering data from my first SSD failure (an almost three year old OCZ Vertex 2). As failures go, this couldn't have gone better. I'm able to read the drive, but I can't write to it. I wish all drive failures were this nice. I'm having Newegg overnight me a Samsung 480GB SSD as a replacement. I should probably think about replacing the two SSDs that are older than the one that failed, just in case.
Just this year I've lost two 1TB hard drives, and one of them somehow corrupted my (thankfully backed up) RAID 5 making it unrecoverable. So, I decided to replace the older consumer grade 1TB drives with 3TB WD Red drives (supposedly enterprise grade), and what do you know? One of them is dead on arrival. WD replaced it with a "recertified" drive, which is annoying, but at least it works.
I also lost a Blu-ray drive, so it hasn't been a good year for my storage devices, but so far my anecdotal experience has SSDs with better reliability than mechanical drives. YMMV.
Why do you think make -j 4 or make -j 8 makes a noticeable difference on even single core machines?
Uh... in my experience, they don't make much of a difference. They slightly increase performance due to one process being able to compile while another process is doing disk I/O, but it's not a huge difference. Shouldn't your build system be piping data between processes rather than writing intermediate files out to disk?
The only step of the build process on my C++ projects that is significantly I/O bound is the linking step, and even then, it's only an issue if I'm linking in a large static library.
Karma: Terrifying (mostly affected by atrocities you've committed)
Sure, you can compile in RAM, (my commercial work project with a ~4GB build tree does this whithout a ramdisk just fine) but linking in ram is right out.
And since in C++ linking is the slowest part by FAR on rotating disks, SSD offers an immense benefit.
If in some other language like pure C or ocaml, then this may be less true.
But then again just building the dependency graph for make wins so hard on SSD, there's still no reason to forgo it. And if you have to build ANYTHING with visual studio, the whole-project link-time optimizations make linking so expensive that you really desperately want the SSD.
-josh
Depends on many things, including the compiler, the language, the relative size of the project and how many files it's spread over. It can be somewhat limited by both..ie an increase in performance of either storage IO and/or CPU/ram offer boosts.
Even on Windows it's easy to move "My Documents" off of C:.
Uh, no, it's not.
Kludgily moving some files out of there to a different drive is easy enough, but getting the whole user tree onto another drive is a huge pain; I had to boot into some special hidden mode during the Windows install to do it. And some programs still continue to write to the C: drive regardless.
Having a lot of RAM isn't going to make the initial read of files from disk or writing to them any faster.
Karma: Terrifying (mostly affected by atrocities you've committed)
Seriously, git is instantaneous, greps and compiles are ludicrously fast, etc,, etc, etc. I mean, unless your rate is like 10USD/hr, you owe it to yourself and your clients to install a decently-sized decently-fast SSD in all of your dev boxes
Since when is compilation an I/O limited activity?
And since in C++ linking is the slowest part by FAR on rotating disks, SSD offers an immense benefit.
How?
You've just built those files, so they're sitting in the disk cache. Is writing out the linked file really that slow?
Oh, hang on, you're compiling in Windows. Doing a clean build of our C++ source tree in Linux, we spend about 99% compiling and 1% linking.
5% of a 4TB HDD that sells for USD$200 is roughly 200 GB = $10.
1.5% of a 4TB HDD that sells for USD$29,000 is roughly 60 GB = $425.
I can guess who is pushing these casual comparisons, but seriously - when price parity kicks in, let me know. In the mean time and as a developer, I have no use for SSD in my desktop system.
If capacity is all you're looking for, SSD lags spinning media. But few people buy an SSD for the storage capacity, they buy for the IOPS.
A $300 15K rpm Cheetah 450GB SAS drive will give around 200 - 300 IOPS.
A $400 Seagate "600" 480GB enterprise SSD will give around 11,000 - 80,000 IOPS
So, 50 - 250 times better performance for 33% greater price. I'd say that price parity is already here.
I'm surprised that as a developer that you see no use for an SSD in a desktop system. I could understand not putting on in a laptop where you might have only a single drive bay, but in a desktop there's usually space to tuck one in somewhere even if there's no free drive bay. And the performance gains are quite noticeable.
Sounds like using symbolic links would help you out.
I've been storing my ( >600 ) steamapps folder on another HDD for years.
RUGBYRUGBYRUGBY
When you had to do this clean build, were you in a critical code-writing/code-debugging loop? That was my main point. How often do you upgrade all the libraries in your project necessitating a clean build AND you're in a critical build loop?
Yes, but that has NOTHING to do with using an SSD to improve performance, unless you have 19TB on your primary desktop with a single HDD, which obviously you don't.
I can tell you have never used an SSD. At a certain point, more RAM becomes hardly noticeable. That SSD drive I got was the single most noticeable improvement in productivity I've gotten out of a computer part.
Fanboy Status: Apache Flex, C#, Eclipse, KDE, Pirate Party, Ron Paul, Slackware, Windows 7
Compiling is almost ALWAYS IO bound for a project of any size. Why do you think make -j 4 or make -j 8 makes a noticeable difference on even single core machines? Because the compiler spends most of its time waiting on disk IO, reading and writing all those intermediate files.
From my experience when I toyed around with Gentoo a few years ago, make -j worked best when the number provided was {core count + 1}. Any more than that and it slowed down due to context switching overhead and/or disk head thrashing.
VisualStudio also supports parallel compilers for this exact same reason.
It has severe limitations. It doesn't work when you need to import TLB files, it does not work with incremental rebuilds, and it doesn't play particularly nicely with precompiled headers. The former is required for our project to build at all, and the latter 2 improve productivity more than using multiple threads (YMMV).
There's DOA and there's failed after use.
I'd be willing to bet a fair amount of the hard drives are DOA. You don't lose data if you never put any on it.
It doesn't matter. Time is money, and SSDs are freaking cheap compared to developer time. While I was not completely idle the whole time, I was less productive since I was mostly concerned with a new version that supposedly fixed some critical issues. And even with an incremental build 20-30 seconds 30+ times a day over a large project adds up!
Honestly I have no idea what your point is here. Are you honestly trying to tell me with almost no information into my situation that an SSD is not helping *my* productivity, or are you just bored and trying to be contrarian?
And again to reinforce the "It all depends on your codebase and tools, really" - dynamic linking is most definitely NOT relevant to all projects. Sometimes it's worth the performance gain not to do it (especially with embedded systems or game consoles) and sometimes it's not even possible with the architecture....
And tape is for infinite amount of porn?
What I'd like to know, why the hell can't they make SSDs that have a life in the ballpark of a ram module. Yeah, you wouldn't buy new ones so often, but come on, crap is crap. Oh, now I can hear all the tablet and ultrabook fans (I also use ultrabooks with SSDs for quite a while) that they are good and nice. But it's not just those devices that SSDs are used in. E.g. we have an application that needs lots of ram and also needs lots of disk space with quick access so we use SSDs for caching important parts. And we've seen SSDs die in weeks (!), while we have 1-2 failed ram modules per year. Yes, different tech, still: make higher quality crap, that's all.
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
I can tell you have never used an SSD. At a certain point, more RAM becomes hardly noticeable.
And for a heavily C++ templated app, the IO is almost irrelevant (RAM and CPU predomine).
While for a Java project, Eclipse compiles the source while saving (me pressing Ctrl-Save is likely to take more than the compilation and writing the file to disk).
Not to mention that, for many compilations, the intermediary files may safely be generated on a RAM disk.
Yes, sure you are right: didn't use one because I never felt the need for an SSD while dev-ing. Certainly, the fact I'm not required to use Visual Studio or the like helps.
Questions raise, answers kill. Raise questions to stay alive.
Semi-OT: A word of friendly warning:
A couple of months ago (year?) I bricked a 120GB Intel 520 w/ the latest firmware (not sure
if it was 400i) w/ ext4 on Fedora x86_64. (Second bricked SSD in 12
months)
A *very* short power shortage crept under my APC UPS and bricked the SSD.
Amazingly enough, the power shortage didn't crash the machine - which
continued working off the main HDD software RAID array.
Luckily for me I rather distrust SSDs (see below) and use it as fast
cache-of-sort, so I only lost a couple of hours of work. (If any)
IMHO SSDs have one huge drawback: Unlike HDDs that can be partially
recovered from more-or-less any type of damage by recovering data
around bad sectors or replacing a fried controller board, SSDs complex
write scheme and the resulting complex firmware usually means that any type of
damage / firmware error will completely bricks it leaving more or less zero
chance of getting the data back.
On the top of that, we (as in all of us) have 40+ years worth of
experience in predicting the life cycle (and death) of HDDs. There's
far less information about the life cycle of SSDs.
Case of point: A couple of days after this incident a family member lost one of his HDDs.
Unlike my dead SSDs, with some work I managed to recover 95% (or more) of his files.
Don't get me wrong. SDDs will replace HDDs in the end - but in the mean time, I'd keep SSDs for non-critical tasks.
- Gilboa
If your compile time is 8ms, you are probably compiling some school project.
-- All that is necessary for the triumph of evil is that good men do nothing. -- Edmund Burke
The 840 evo is a piece of crap, it has got very few write cycles.
RAM disks are for compiling for those who don't really understand how a modern OS buffercache works.
RAM drives (not disks) are for compiling for those who understand the difference between circles and squares. /boot/ for those who want instant-on and the same security of UEFI (even on x86) without the cluster-fsck of UEFI.
Modern OS IO caching is a crutch for poorly written software systems that should be using a daemon if they need that performance.
Additionally: Firmware is for
Since cpus have been so much faster than disks.
All this discussion on this and no one has commented that TFA is from 2011??
This article isn't reliable information. It's from when SSDs were relatively new and definitely doesn't apply to the in-the-field results people are seeing in 2013.
Reeses
What about putting 2 SSDs into a software RAID 1 configuration? Does that solve the problem?
What you said is my experience, also. I haven't had catastrophic failure of a HDD in perhaps 20 years in a population of perhaps 15 computers. In my experience what most often fails is the HDD electronics, so it is possible to extract the data by temporarily replacing the HDD electronics with a circuit board from another, identical HDD. Also, of course, in the last 20 years we have replaced HDDs because of frequently replacing computers.
Perhaps you need to buy some more RAM? :)
And desktops started having many more cores than disks.
Don't put so much weight on warranty lengths.
You might want to factor in that OCZ's stuff are often even crappier than HDDs:
http://www.behardware.com/articles/881-7/components-returns-rates-7.html
http://www.hardware.fr/articles/893-7/ssd.html
Either OCZ sell defective hardware or OCZ users are many times more likely to return stuff for no good reason. I'm more inclined to believe the former.
And the thing to remember about all storage is that it will fail. If you have a single disk in a machine, and that machine is not backed up properly, then you will lose that data in the next 5 years.
The trouble is, you're probably wrong. Sure, storage will fail eventually but it's generally good enough to last the working lifetime of the machine. Plenty of home users still run XP because their machines are older than that.
Some days, I do get bit nostalgic for the days when hard drives were like that and backup/replace failed drive/restore were routine operations. Nowdays, it's a little bit more like DR: 90% chance you won't need it but then you *really* need it.
The SSD that most consumers are using are neither high end nor have such IOPS ratings.
False on the second part. Even the cheapest entry level 250GB drives these days score >90k IOPS. Performance on the cheaper drives has more than tripled in the last 3 years.
Which SSDs are they using? How slow are the slowest Samsung, Plextor, Intel, Crucial, Corsair SSDs being sold today? Which of their SSDs can't do more than 10k IOPs? 10K is still 100 times more IOPs.
One "problem" I had recently was I couldn't use my SSD equipped laptop to test some DB optimization (e.g. what indexes to drop/create, which query would be better) - stuff that was slow in production was acceptably fast on my laptop (10-20x faster).
9ms average access times on a 7200RPM spinning drive == ~100 IOPS.
High-end SSD: 100K IOPS.
The SSD that most consumers are using are neither high end nor have such IOPS ratings.
And this weeks Stating The Fucking Obvious Award goes to... Desler.
Consumer drives will not be as fast as enterprise drives be they solid state or spinning.
If I set up an array of consumer 10K RPM drives in my gaming boxen, do you think it will be as fast as the 10K RPM EMC boxen I have in the server room?
Of course not, nowhere near as fast.But call me when the home user has enough spare cash to drop on an entry level AX4.
You'll find that consumer spinning drives are not as fast as enterprise spinning drives.
Calling someone a "hater" only means you can not rationally rebut their argument.
They sell several amounts of already soldered chips on the main board.
Not soldered to the motherboard for the 15" Retina MBP and not soldered to the motherboard for the 13" Retina MBP. On which Macs is the SSD soldered to the motherboard?
And for most single-user uses, that's fine. I just kicked off a run of the LLVM test suite, since it was the first thing I could think of that would cause a lot of I/O. It was doing 1000 random reads and 500 random writes per second on my (two-year-old) laptop's SSD. It wasn't a great benchmark, because it was CPU limited, even with a quad-core i7, but that's largely the point of the SSD: the CPU is now the bottleneck, whereas with my old machine (spinning disk and Core 2 Duo), the same operation was I/O limited, even with a CPU less than half the speed.
I am TheRaven on Soylent News
If you're compiling a single file, not doing a parallel build, and having all of the headers already in cache, then you'll probably see about that kind of speedup. If, however, since this isn't the 1960s anymore, you're working on a codebase with a few hundreds or thousands of files, doing a parallel build, then you'll likely see your builds take about half as long. Less if you have a faster processor, because they're now going to be totally CPU limited and not I/O bound.
I am TheRaven on Soylent News
The links are not consistently followed. Symbolic links on NTFS are sadly untrustworthy apart from in a few cases (eg. file explorer) unless Win8.1 has done something about it.
What about Corsair Force Series F115 (115 GB; CSSD-F115GB2-BRKT-A)? :P
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
Cry me a river
Out of 15 SSD tested, only 2 are failure proof under power fault (only one maker and model).
(yes, I've read the pdf)
I'd like to know who is the winner, the anonymous vendor/model called "A-2".
It is not the most expensive, almost the cheapest, but it has at least a power-loss protection.
Another vendor has power-loss protection but his models failed the tests.
Direct link to pdf and figures erratum.
Bit Corruption: SSD#11, SSD#12, SSD#15
Flying Writes: none
ShornWrites: SSD#5, SSD#14, SSD#15
UnserializableWrites: SSD#2, SSD#4, SSD#7, SSD#8, SSD#9, SSD#11, SSD#12, SSD#13, HDD#1
Metadata Corruption: SSD#3
Dead Device: SSD#1
No failure: SSD#6, SSD#10, HDD#2
Their last word conclusion :
We recommend system builders either not use SSDs for important information that needs to be durable or that they test their actual SSD models carefully under actual power failures beforehand. Failure to do so risks massive data loss.
Thanks again for this link to the Usenix study, too bad you posted anon (patent need mod up).
i was speaking to someone who works in aerospace: they have deep concerns about the geometry shrinks in the chase for extra storage. the smaller the geometry gets, the less reliable it gets, it's as simple as that. they are having enormous difficulty getting hold of large-geometry small-capacity NAND flash ICs.
also, i've begun to replicate the drive-torturing software which was mentioned a few months ago here on slashdot. one SSD i tested which is reported to have good power-loss protection failed in THREE minutes. another took 24 hours and 2,500 power-cycles.
I have seen SSDs fail too often to use them for anything but read-only storage.
I have gone back to HDDs simply because they are more reliable and lasts 10 times longer.
An SSD in a desktop computer lasts for max 2 years, and if you power it off while it is working, then it is a sure way to kill the entire drive or at least all the data on it.
SSDs are great toys, but never use them for anything other than read-only data.
No he's doing the math right -- At an annual failure rate of 1%, you need to replace 1% of your total capacity every year. With an annualized failure rate of 5%, you need to replace 5% of that capacity overall.
No you don't. The figures pertain to SSDs and HDDs under warranty. So you get to send 1% of your SSDs back to the manufacturer to be replaced for $0.
The figure also does not mean that 1% of your SSDs will fail
You might have forgotton the point about most people don't take adequate backups, and many people have personal photos with intangible value.
I read this instead.... if there were 1 milllion of a model of SSDs manufactured in the world in a particular year, and you bought 1, then you have 1 out of 1 million SSDs.
If the annual failure rate of that model is 1%; then 10000 of those 1 million SSDs will go bad in year 1.
You don't have a chance of losing 1% of your data from your one SSD. You have on average a 10000 in 1 million chance of losing all your data in one year.
Now in year 2.... since the annual failure rate is 1% You will have had a 10000 in 1 million chance of losing the SSD in year 1; and then a 9990 in 999000 chance of losing the data on the SSD in year 2..
Are you going to say you lose twice the cost after the end of year 2?
It's nonsensical. You will return the SSD under warranty, and receive your replacement What you lose is the data, not the SSD unit
Realize that the study examines warranty claims, so there isnt such a thing as putting too much weight on warranties.
The thing with OCZ is that they have absolutely put out inferior hardware compared to their competitors. They also have, until recently, offered cheaper SSD's than all equal-performing competitor products.
Its no surprise that the cheapest item on the market is also significantly below the quality curve (the opposite would be a surprise.)
I would only trust the quality of a company that aggressively undercuts its competitors if there is an obvious reason why they should be able to. Companies in the SSD world that would have obvious advantages on margins would be Intel, Samsung, and SanDisk - each because a portion of the product is entirely produced in-house (the flash chips themselves.) Note that none of these companies are aggressively undercutting the market. SanDisk has put out some very nice deals from time to time, but they clearly would rather sell their flash chips to other manufacturers. since there is no way in hell that they could saturate their production lines without outside buyers.
"His name was James Damore."
OK, and if you are working with hundreds of files, then you are compiling on a cooperate mainframe. I never tried to say that SSDs do not have a user case for compiling, but that use case is not consumer. I am physically unable to create a project, by myself (or even in a small group), big enough to warrant an SSD.
Troll is not a replacement for I disagree.
I've been using SSD's for a few years now and I'm NEVER going back to traditional hard disks for boot drives. I moved myself over to SSD boot disk a few years ago, maybe 5, In the last 5 years I've had 1 SSD die and it was replaced with no questions asked. If I look at how many traditional hard disks I lost in 5 years when I was using them as boot and storage disks I would probably average 2 or 3 a year. SSD technology is quickly becoming the only sensible solution for computing, not only does it last N times longer then traditional hard disks, it's faster and more rugged.
The averaging is done because over time, it works out, just like insurance.
Insurance would not average in that manner.
My argument is average cost of capacity failing per year isn't a valid measurement, even if you could justify it. Price and failure rates are not constant; therefore picking an arbitrarily extreme capacity doesn't have much validity. Failure rates are higher with larger capacity units; such as 4TB drives or theoretical 4TB SSDs. Prices per capacity unit are larger with larger capacities, beyond a certain point which is media-specific.
Prices and failure rates vary with time. A SSD that costs $100 today probably costs about $50 a year from now.
The same HDD that costs $80 today probably costs about $80 a year from now.
Because most of the expensive HDD components are mechanical; there are manufacturing costs involved that won't go down. SSDs on the other hand, have most of their costs concentrated in IC and board designs that are constantly being improved and shrunk into smaller and smaller forms.
If those numbers were valid, SSDs would be coming with a much shorter warranty, because the cost to the manufacturer is enormous, since the manufacturer essentially has to pay for all the failures within warranty, to give you the free replacement....
The fact is... you don't buy 4TB SSDs, you just don't.
With 40 100gb SSDs; you might expect to have a drive fail every 4 years, with a variability of 0 to 4 drives failing in any given year, but it's much better than having 1 4TB SSD, and 0 expected drives failing every 4 years, with a variability of 0 or 1 drives failing in any given year.
The other thing is capacity is not unit neutral; the fewer units you distribute capacity over, if you maintain the same failure rate, the less likely a failure, but the higher the variation --- in other words, with large capacity units, your failure is unpredictable, the more units you distribute the same capacity over, without changing the annual failure rate, the average capacity lost increases, but the variability narrows, because your failure rate is predictable.
I would argue most people do not buy enough SSDs or HDDs for it to work out, especially not in those capacities.
It's not like you go to the store -- and buy a new SSD at the full price you paid at the beginning of the year for a brand new one; their price is not constant but a function of time, AND under warranty, the manufacturer pays this.
The valuation of capacity for the consumer is wrong, when the manufacturer bears this particular cost.
Again... your cost is the lost data and lost productivity.
These costs are maximized using units that are 4TB in capacity, if the smaller units have the same failure rate.
Curious,
How many libraries are you actually linking to your projects? Do you actually need them all?
Surely limiting the use of library links, and, optimizing your program in the process. Is more important to productivity than how fast your HDD can link unnecessary library links?
Linking a game engine as a .dll:
My current code size is 2mb in the project, and, it takes me 2 seconds to compile on a "trusty rusty".
I do, and so does everyone else on my corridor. Yes, we also have machines in racks that can build things faster, but with a quad-core i7 and an SSD in my laptop, I can build the LLVM codebase in 5-10 minutes, with incremental builds often taking under a minute, and that's a big win for my productivity over spinning rust. Most software projects that I work on have been ongoing for 10 or more years and in that time even a small team can produce something that has thousands of source files.
I am TheRaven on Soylent News
I don't know if mechanical HD's are considered "Amish technology" in the PC world yet, but I've been using computers since the 80s and have yet to have an HD disaster. Could be luck, could be karma, but I have no desire to switch yet. Even the typical sales pitch of "bigger, faster!" doesn't sell me like it does with GPUs.
OK, so it is a consumer use-case, because compiling is so fast that it is not worth using the companies machines, but it is slow enough to pay a few grand to half the compiling time? Why not just network to a central repository on a super fast, SSD carrying, mainframe.
Troll is not a replacement for I disagree.
I have a build machine that has 24 cores, 256GB of RAM, 256GB of SSD, and 4TB of spinning rust. Building on the SSD is significantly faster than the spinning rust (factor of 2-4 depending on what you're building). Building on the RAM disk is probably 1-2% faster, but within the noise for subsequent runs. I often put the object files on the RAM disk though. It doesn't seem to impact performance, but it means that the OS never has to bother writing them out to disk, which should help the SSD last longer when I'm generating 2-30GB of object files per build.
I am TheRaven on Soylent News
Uh, what? Compiling is so fast on an existing, consumer-grade laptop with an SSD that for incremental builds it's a productivity boost, and it works when I'm at home, at work, on the train, or whatever. The difference in price between the SSD and a mechanical disk was about £300, two years ago (for a 256GB disk). It's now even lower. When I'm doing a lot of builds in different configurations I'll use a centralised server. When I'm actually hacking, I want my working copy to be local. The entire point is to speed up the edit-compile-test cycle, and sticking a network in the middle does not do that.
I am TheRaven on Soylent News
You will however find that consumer SSDs beat the ever living shit out of any Enterprise SSD. Actually I have tested consumer vs enterprise hard drives and they are pretty close. That EMC box is doing a lot of magic to hide how bad hard drives are.
A few grand? You can get 128G SSDs for $100.
If you have a laptop simply their G load tolerance makes SSDs a no brainer.
How big are yours? Ram is cheap. You can get normal middle of the road laptops with 16GB of it.
So one guy who failed to to proper benchmarking before is your evidence?
If you don't know what your bottleneck is going out to buy hardware is a stupid move.
Actually, it's the same in Windows. I dunno what k8to is doing, but for most people it's the compile that takes a lot longer; linking is relatively quick.
If you just stop and think about was work the compiler has to do, versus what work the linker has to do, it makes sense.
I'm generating 2-30GB of object files per build
I'm not sure if I should be impressed or disgusted. It's actually a little of both.
Use of the words "good", "bad" or "evil" is almost invariably the result of oversimplification.
Another idea is to mount a partition using a junction point (Windows's analog to UNIX mount points.) That way, it might be happy storing its stuff under c:\Program Files\blarf, while directory blarf is actually a different partition.
I do this for Cygwin which makes so many small files that a chkdsk takes forever, so the Cygwin stuff goes on a different partition.
A debug build of LLVM generates over 2GB for the debug info. Much of this is removed by the linker. For FreeBSD, it's the userland for 6 architectures when I'm doing a test build and a few dozen kernel configs. It adds up quickly.
I am TheRaven on Soylent News
So you would rather spend $250 for a 150GB SSD drive instead of $60 for the smallest magnetic drive you could get (lets assume 320GB) just so you can fill the drive and not feel like you are wasting storage space?
Sorry, I don't follow the logic.
This is not flamebait, its correct:
If you don't understand why, read up on annualized failure rates. Someone get out your informative mod and read the parent.
- Michael T. Babcock (Yes, I blog)
Your entire post is nonsensical. Nowhere in my post or the gp to my post did we assume anyone loses data or doesn't do backups.
I do drive allocations for enterprise customers, we sell dozens of drives, not one or two. We make people do daily off-site backups. We enforce RAID-1 minimally for all storage. This all comes from understanding annualized failure rates on drives, which is what I posted.
Once you understand how drives fail, and what it will cost you to replace them, you can plan ahead for those costs.
Understanding *that* they fail at all means using RAID for high availability systems and backups for all systems.
- Michael T. Babcock (Yes, I blog)
Yawn, your posts are boring me because to some of us the math is too obvious to be bothered explaining to others.
It is in fact *exactly* how insurance companies work. They know they need to plan ahead for N payouts of X dollars, that a specific insurer has an M percentage chance of making a claim of Y dollars, and charges them Z per year to cover that annualized cost of those possible payouts (plus profit in their case).
If you're not doing the same math for hardware replacement, especially in business, you have no business making computer decisions.
- Michael T. Babcock (Yes, I blog)
OK LOL!
HDD give you plenty of warning now. In fact most of SMART tech, and a host of other things to run continuous tests looking for potential failure, as well as OS that specifically look for indications as well. Now.
Years ago, this was not the case. You MIGHT get some warning depending on how it decided to fail (bad sectors etc.,,), however most back in the day gave you about one second of actually notice before dying in a grinding crunching sound, or in a small black puff of smoke. I suppose in that light, you aren't wondering what the matter is, as you know it died, as it had the good measure to give a last death rattle before departing into the dark night.
Backups had to be done all the time, because at any time, it could go poof. Now you get like a weeks warning and can go pick up an external drive at your leisure (which is what I did the last time I had a HD fail).
The reason we have the protections is because they were so bad, and consumers demanded better drives, driven by consumers. SSD drives have only been mainstream commercial for a handful of years. It is pretty new technology compared to HDD. Give them a second to catch up!
As I got a mSATA SSD which plugs into the back of my motherboard, and my case has no removable back plate.
I hope that thing never fails, as if it ever does there is no way in hell I am going to disassemble everything just to get that POS out.
That said, if it is still under warranty I will probably have to, sigh. Word to the wise, if your building a system using a mSATA SSD, you might want to make sure your case has a removable back plate.
Though the thought of using a dremel to cut a hole just briefly passed through my brain, though I suppose the MB wouldn't react too kindly the the pile of steel shavings it would produce...
Note to Fractal Designs: Your Node 304 uses ITX format motherboards, most of which support mSATA SDD, and there is limited HDD space in the case. How much more would it really cost you to make a removable back plate? Not to mention the back plate that most modern heat sinks now require also (and yes I forgot this and had to redo).
The MLC aspect is the biggest problem, even more than the SLC shrinks. Having 4 different well regulated states in which to store data, even while the core VDD keeps decreasing due to the shrinks, makes data corruption even easier. If I know that an SSD is based on MLC technology, I'd avoid it like the plague.
As the shrinks take place, it happens for not only NAND flash, but NOR flash as well. As NAND flash hits the several TB range, we know that NOR flash can as well. If they make SSDs based on SLC NOR flash, and price them somewhat higher than the current SSDs, they can actually realize the claimed theoretical advantages of flash memory over HDDs, since w/ NOR flash (think of the flash memory used in the BIOS of your PC motherboards), you don't have the issue of corrupted bits, low data retention or any of those associated issues
Yea, I have to call bullshit on this one. I have been building PC's for years, since the end of the 1980's. On only 3 or 4 occasions since I have started building machines have I had spinning platter drives die on me while I am still trying to use them (typically 2-3 year replacement cycle for me). Since I have been purchasing SSD's, I have lost one a year, consistently, because the NAND fails. I have bought SSD drives manufactured by Corsair, WD, OCZ, and most recently a Samsung. Only the Samsung is still alive, but it's only 2 months old. All of the others stopped working at right around a year, you get a replacement under warranty, and then that one dies within a year. These drives have gone into both my machines and those of my kids. These drives are heavily used, there are a bunch of read/write, but with these new claims of the drives lasting a "normal user" like 70 years, it's bullshit for them to die for ANY user within a year consistently. These claims appearing on tech blogs is complete marketing spin and a disservice to normal users, as only ONE of the drives made it more than 12 months, my OCZ, which lasted 14. I live in an air conditioned condo with no water problems, normal humidity, and the drives are positioned so as to allow proper cooling (with a fan blowing over them). It isn't an environmental issue killing them, it's the fact that these things aren't made to last. I still have had the same Caviar Green platter drive for data for 4 years now, and while it isn't as fast as an SSD, it hasn't died either. Until the in practice life expectancy gets up for these thins, users who want better speed will be forced to continually replace them year after year (I now use a mirrored setup to prevent data loss). The performance is great, but it's a shame that the longevity is awful.
Most workloads are in fact dominated by small, mostly random, reads and writes, which is why SSDs are just that much faster in the majority of cases.
If you're talking about mainly sequential reads, then the situation for the four RAID1 HDDs is even grimmer. RAID1 provides virtually no speedup for single reader sequential reads, as to do so would require tons of seeks from the drives (which as we know, HDDs fail at), or an extremely large file and very large stripe size (and also a matching amount of memory for intermediate buffers). Most RAID1 implementations don't even bother trying.
Having said that, HDDs are substantially better at sequential reads and writes than random ones, and if your workload really, truly is dominated by sequential operations (and it probably isn't), you can generally match the performance of a single SSD with a RAID10 of roughly a dozen HDDs (or a RAID0 of half a dozen, but say goodbye to reliability). This ignores the fact that a dozen of even the cheapest HDDs is substantially more expensive than an SSD, due to actual unit cost, the extra power draw, the extra physical space required for them, the extra HBA(s) to plug the drives into, the extra manpower to install/manage them and the extra manpower to deal with them when they die.
There are still reasons to use HDDs, but performance is absolutely not one of them. It's not even close. Take it from someone who manages several hundred HDDs + SSDs.
Game! - Where the stick is mightier than the sword!
Go to the Apple Store, configure a 15" Retina MBP and find this greeting:
Storage Your MacBook Pro comes standard with 256GB or 512GB of flash storage. Please note that the flash storage is built into the computer, so if you think you may need more storage capacity in the future, it is important to upgrade at the time of purchase.
What that means is that Apple won't upgrade it after you buy the machine. "Built into the computer" does not, as the pictures on the iFixit pages indicate, mean "soldered onto the motherboard".
Are they really? Not in my experience. Symbolic links are most decidedly not "shortcuts".
Why did you not use a symbolic link to another drive and copying the entire /User tree using xcopy or Explorer?
Ah, that's pretty reasonable compared to whatever I was imagining.
Use of the words "good", "bad" or "evil" is almost invariably the result of oversimplification.
For starters, SSDs are being marketed as mainstream replacement for HDDs -- not as exotic high-performance upgrades. (So that Ferrari analogy is pretty much invalid here.)
Sure, they outperform regular HDDs -- but Core i5 and i7 CPUs outperform older Pentium 4 core-duos too, and those outperform PIII processors by a long-shot -- yet you don't expect them to be far less reliable just because they're faster. If anything, the promise was the lack of mechanical moving parts would virtually guarantee they last longer.
If you're really a developer, you'll see your compile times cut by a factor of 5-10
Please tell me, in what circumstances sources you're building are not already in memory?
And even if they were not, just increase the -j level by one so no CPU time is lost waiting for I/O. So both builds will be CPU-bound.
Sorry, but if your compile times change noticeably, much less by a factor of 5-10 as you say, you're doing it wrong.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
here's another: when I switched to an SSD at work my compile times were cut by more than half
Here's a -j switch for you. Please learn how to use it. If any part of the compile is waiting for the disk, you'd better fix your tools.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
that's largely the point of the SSD: the CPU is now the bottleneck
Yep, it moves that bottleneck around. I have an older Core Duo chip in my 2007 era laptop and I can tell when I'm CPU-pegged now. It's the only thing I don't like about my Thinkpad right now (8GB RAM, Win7, 300GB SSD). But everything else works perfectly, so I put up with the slower CPU and don't plan on upgrading until 2015 or 2016.
(At which point my laptop will be 8-9 years old.)
It helps that I have a 4-core Linux server and an 8-core Win7 desktop that I can use to offload CPU-heavy stuff to (such as video encoding / transcoding).
Wolde you bothe eate your cake, and have your cake?
That may be the case if you're compiling something on an old PC that has 128MB of ram or something. But nowadays when I have 10GB+ of ram sitting around that can act as a disk cache, it's a non-issue.
If you don't know what your bottleneck is going out to buy hardware is a stupid move.
He was upgrading to SSDs, so he did a test before and after the upgrade. He didn't say that he was upgrading specifically to speed up compiles. He also said that everything else worked much faster on his computer, so he was happy with the purchase. (So, your criticism about how "stupid" he is for upgrading kind of misses it's mark.)
Understanding *that* they fail at all means using RAID for high availability systems and backups for all systems.
RAID is not adequate for SSDs, because they have failure modes that are related to characteristics of drive longevity and created by the pattern of wear (interaction with wear-levelling on specific models) -- number of writes over time.
That is; correlated failures between RAID mirrored pairs are more likely than not with SSDs used over long periods of time.
Therefore: with SSDs, duplicate data makes sense, and RAID does not.
Of course we have build servers - dozens of them running incremental builds in every checkin, as our platform is running on hundreds of different devices. But this thread is about SSDs in workstations for development - for developers who build and test their changes before checking in code (many of which may not have dedicated servers anyway).
The sort of programs we are discussing don't know enough about NTFS to be able to deal with the difference between the links and real files. They are not presented to the application as if they are real files as in other filesystems with symbolic links - it all depends on the application understanding extra metadata and if the writer of the application has not thought of that it doesn't happen.
Thus often pointless for the sort of programs that need to be fooled into where a file is located. Of course the real answer is to fix the application, but once again the conventions of the MS Windows environment are that only the software vendor can do that.
Nobody said the RAID set would be two SSDs.
cf. http://tansi.info/hybrid/
- Michael T. Babcock (Yes, I blog)
Yes and no. SSDs offer much lower latency and can handle near instantly the common small, mostly random, reads (and writes, but that's heavily covered with RAM caching). But the common workflow rate is nothing closer to on the order of 90,000 IOPS. Instead, the issue is more that spikes in most workflows can reach the low thousands range and HDDs will strain for seconds to fulfill requests*. Hence, the actual performance difference is on the scope of SSDs being 5-10x faster. It also heavily implies that with a proper RAID1 implementation ferreting out requests that a lot, though not all, of the read requests could scale near linearly across all the drives. The main issue, as you note, is that plenty of RAID1 implementations likely don't do such things well if at all (although I wonder if what you say holds true for Linux's dm-mirror (which I know isn't strictly RAID1, and you can readily fault me that I wasn't necessarily strictly speaking of the official spec RAID1 but primarily of a fault-tolerant mirroring system)).
Except my point wasn't that HDDs are better performance wise, even in a RAID configuration. It was that a RAID of HDDs could obtain a better fault tolerance rate and still see a substantial performance spec of SSDs (really, you should look at the benchmarks I linked to before or try to find other workflow examples to see just how big of a difference in scale having 1000x the possible IOPS really has on most use cases) with the unstated point of relatively cost being a lot less--and 4TBs were admittedly a bad example because 1TB (on the order of $60/drive) are more than sufficient for a comparison given the SSD price range for such things. I don't think your notes about power usage hold up--4 6W drives** work out to be ~1kW*h/1.736 day sustained or ~$31.53/year at $0.15/kW*h--figures I think are just overboard to realistic. Maintenance and enclosure costs are the real killers, I think, although the former has to be weighed against the downtime costs on an SDD system vs a RAID system and the latter can be possibly avoided (presuming maintenance is done after hours and computers were bought with sufficient internal space for the necessary drives--admittedly a possible blocking issue).
In any case, yes, SSD is the clear winner as far as raw performance goes. But the whole article was about reliability. And you and others keep bringing up IOPS as if they remotely linearly scale to real world performance (they rarely do). Meanwhile, RAID HDDs offer a pretty clear middle ground for a lot of people who care about reliability first and can still see performance gains in many cases. But, I'd readily defer to your experience upon the subject. I'd just prefer some actual numbers to back it up rather and some clear observations to sustain that position than using vague words like small and big or random and sequential or focusing on IOPS when throughput is a major factor too in judging things too :)
*I base this all on personal observation of actual throughput on systems which varies greatly but can readily sustain in the 7MiB/sec to 20MiB/sec range which based upon 120IOPS implies minimally common sequential reads/sec of at least ~60KiB to ~170KiB blocks (presuming saturated IOPS) and likely much higher actual numbers since I doubt IOPS requests are actually commonly saturated. Of course once you do get to saturated IOPS on a HDD you are looking at a potentially dismal (presuming 4KiB/block) 480KiB/sec while SDD is likely only limited by its ability to saturate SATA or whatever the connection is. Yet benchmarks rarely bare out figures like that (that I've seen, anyways)
Eurohacker European paranoia, gun rights, and h
Yawn, your posts are boring me because to some of us the math is too obvious to be bothered explaining to others.
You mean that it is too obviously wrong.
It is in fact *exactly* how insurance companies work. They know they need to plan ahead for N payouts of X dollars, that a specific insurer has an M percentage chance of making a claim of Y dollars, and charges them Z per year to cover that annualized cost of those possible payouts
The point is, "that a specific insurer has an M percentage chance of making" IS NOT THE SAME QUANTITY as the percentage of the insured that will make a certain claim; the two numbers are not interchangeable, that is to say: they cannot be substituted for one another.
Probability of a single member of group G failing not equal to The proportion of members of G expected to fail.
And when we have small number of SSDs..... well.... nobody buys "4TB" SSDs; and I never heard of anyone buying "4TB" HDDs, if they even make them. Both of those things are obviously so contrived.
I would have thought that SSDs are ideal candidates for integration into a HHD/SSD hybrid RAID formation. The problem with how SSDs go, is there's no warning. One day, they just.. stop. We all know about the ""click of death" in a standard HHD, whch usually gives us enough time to run to the shop and find the only available drive has half the capacity of the one that's failing ;-). We do get time to get the data off , though... Not so with SSDs..If I ever get one I fiully intend to try this hybrid RAID idea.. the best configuration I haven't sorthed out yet, though...
I run about 90% of the systems I manage in RAID 10 (there are a few oddballs in there, some only support 2 drives, those are RAID 1, and there's a few where I don't care about performance, but do care about drive space, those run RAID 5/6). The real world performance difference of RAID 10 over a single drive is very large. Assuming a four drive RAID 10 array, expect between 2x and 4x improvement in both random and sequential read/write performance.
WIth that in mind, at $dayjob, we run a lot of VMs. Before SSDs were affordable, we could usually fit between 6 and 8 VMs on a single host (with 4x or 6x 7200 rpm drives in RAID 10) before they became unusably slow, with tons of time spent in disk wait. CPU time and memory usage were rarely limiting factors. As soon as we started deploying SSDs, the only problem was running out of space. Right now we have over 50 VMs running on a single 8x SSD RAID 10 array, and it's blindingly fast.
There's a similar story with databases. Back before SSDs were affordable, we bought a machine with enough RAM to keep the entire database cached in memory, as it was just too slow to run off of 15k RPM SAS drives. On a fresh boot, we'd still need to precache the database into memory, and with said HDDs, that's a job that took something like 10 minutes and was almost entirely disk bound. We recently upgraded that machine to SSDs, and the same precache task now takes under 30 seconds.
As for home users, well that's a different story. Personally I think it's downright irresponsible to run any system with a single drive (HDD or SSD), but the overwhelming majority of existing machines with a single drive suggest that my opinions on this matter are not widely held.
I guess my issue with your proposal is that I just can't see very many cases where it's practical. The low end of the market is dominated by Laptops/Desktops/Tablets/whatever that cost under $500 and all have only a single drive, as an extra $100 for another drive is going to be a dealbreaker most of the time (if another drive would even physically fit). The high end of the market where performance is critical, is completely dominated by SSDs. You can read countless stories of big companies replacing full racks (42U) of HDDs with 1U or 2U of SSDs. I guess somewhere in the middle there is a small set of people who:
Those people would probably be better served by a 4x HDD RAID 10 array than a 2x SSD RAID 1 array.
* If you're storing media files on SSDs, you either have too much money to burn, or zero sense. They're huge and 99% of the time are read/written sequentially.
Game! - Where the stick is mightier than the sword!
100 IOPS is an accurate number for 7200RPM drive. The 100K IOPS numbers some SSD vendors trot out are best case fantasy.
Last week I watched a 400GB Intel DC S3700 hit its limits for a long period. Intel is conservative on its numbers for this drive compared to a lot of the numbers other companies advertise. They only claim 36,000 IOPS. But here's what a real world worst case for the drive looks like, from a busy PostgreSQL database server:
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util
sdc 0.00 22.80 888.00 483.00 6.82 3.96 16.10 162.34 118.79 0.73 100.00
sdc 0.00 2.60 908.00 422.00 6.27 3.32 14.77 170.80 125.76 0.75 100.00
sdc 7.00 54.20 1102.00 1900.40 11.64 15.26 18.35 166.82 56.68 0.33 100.00
I tell people they shouldn't expect more than 1500 IOPS on real mixed workloads with lots of concurrency from any single SSD. That's great, and it's completely reasonable to say a SSD is always going to be 10X faster than a mechanical drive. But the only devices consistently delivering even a real 100X speedup are the super expensive models from companies like FusionIO, Virident, etc, with matching price tags. And nobody is really doing 100K IOPS in anything but carefully controlled lab benchmarks.
Granted, most desktop users buy a computer as a unit and don't make modifications. Those that do rarely know ahead of time what they want and even if options were available by OEMs, a lot would make poor choices. So, it seems an almost inevitable that only the technically minded who are willing to make modifications are the majority in the middle, without the cash to spend the significantly more on a pure RAID SDD setup. Of course, the same people are liable to just use one SDD as a boot/root device and forgo the idea of RAID. :) And the practical SDD/HDD hybrids which I can only presume have even worse reliability than standard HDDs or SDDs (I don't presume that hybrids do good fall back onto just SDD or just HDD if one part fails) will likely be the major penetration in the desktop arena.
Still, I'd prefer a 4x HDD RAID for the performance/capacity/reliability (the latter is more important to me actually as I've seen plenty of computers die). But, then even I'm in the boat of having a system not designed to physically contain that many HDDs and my system doesn't support eSATA or USB 3.0 for an enclosure. :( So, it's all still too much of a theoretical for me. It's nice to think about The cost of multiple SSDs isn't, though.
Eurohacker European paranoia, gun rights, and h
Yes, sure you are right: didn't use one because I never felt the need for an SSD while dev-ing. Certainly, the fact I'm not required to use Visual Studio or the like helps.
In addition to better performance on some IO-heavy tasks, what makes even a cheap SSD stand out is close to zero access time. Everything is more responsive, large programs launch in literally 1/10 of the time. The performance difference is slightly less noticeable in Linux, but it's still a huge boost. The system is simply more pleasant to use. As drkstr1 says, it's obvious that you've never tried one :)
Every carpenter knows that it's worth it to invest in quality tools, I'm surprised that a developer who presumably does serious dev work would skimp on a crucial part like the system drive. You could probably get by with only 2GB of RAM as well, but why on Earth would you want to do that?
A musician I know who also does a significant amount of studio work asked me if I could help him setting up a Linux computer for mastering. He preferred using a Mac, but would like to save some money going the Linux route when getting a new computer. I advised him to fork out for the Mac instead, it would not be smart for him to reduce the productivity and enjoyment of a significant portion of his livelihood.
Are you a grammar Nazi? I'm trying to improve my English; please correct my errors!
I've been running multiple partitions/drives on Windows for years and haven't encountered a sizeable app that I'd want to put on a different drive that wouldn't let me.
Same here. I've also found that for gaming Steam Mover makes it very easy to shuffle my current games onto the small SSD. It works for any directory, not just Steam games. Windows doesn't know the difference, but some games benefit greatly from living on the SSD. It would likely fool any stupid software that insists on living on C: as well :)
Are you a grammar Nazi? I'm trying to improve my English; please correct my errors!
sigh...
The study is based on warranty claims, which do not happen outside their length. Its important to note the differences in warranty lengths precisely because of that fact.
You seem to think that warranty lengths are not important to the study and the 5% and 1.5% figures... what a fucking retard you must be. The devices with the lower claims rate have longer warranties... you seem to want to insinuate with hand waving that somehow the opposite is true. Dipshit.
"His name was James Damore."
The summary also said they explored failures under warrantee. Have 80GB SSD's even been around as long as a 5-yr-warrantee HD?
How do the SSD's stack up in failures/GB?
Face it, at 98.5% failure rate and 6-8 drives = 1 HD, we are talking,
um... 98.5**6 - 98.5**8 = 91.3% - 88.6% chance of NO failure, or
8.7-11.4% chance of failing in a shorter warrantee period for the same
amount of disk space or 50-100% higher.
I'm actually more of a jerk/asshole than a dipshit. But you're intentionally continuing/pretending to be stupid.
The devices with the lower claims rate have longer warranties... you seem to want to insinuate with hand waving that somehow the opposite is true.
Where did I insinuate the opposite? I merely said you shouldn't put so much weight on them, while you said "the study examines warranty claims, so there isnt such a thing as putting too much weight on warranties."
You yourself mentioned OCZ's SSDs (including the Octane) have 3 year warranties.
Corsair SSD warranties are 3 years - return rates about 1%.
Most of Crucial SSD models have warranties of 3 years. Return rate a little over 1%.
Samsung SSD warranties range from 3 years to 5 years, and the 3 year ones (e.g. 830 ) definitely don't have a return rate anywhere close to OCZ's crap or it would certainly be noticed by now.
HDDs with 3 year warranties still have lower return rates than OCZ's 3 year warranty SSDs some of which have return rates of up to 40%. NONE of the HDDs in the report I mentioned have return rates over 10%.
In contrast OCZ's crap have return rates of 9%, 30%, or even 40% while still having 3 year warranties.
Hence you shouldn't put so much weight on warranty lengths. QED.
You had a chance to stop being stupid in your reply but you clearly chose deliberately to remain stupid.
For the record, you did the insulting first, so you're as rude and offensive as I am if not more so, in addition to being _voluntarily_ more stupid/incompetent, hence you've proven yourself to be the real dipshit in this thread[1].
[1] You might not be a dipshit elsewhere of course.
I've argued with my fellow economists about "diminishing returns to scale" and so far the jury is still out, but seriously leaning my way as some of my colleagues have conceded . Significantly, so long as Moore's Law still applies, we have increasing returns to scale when it comes to capital investments, especially when factoring in intellectual capital. Each generation of tools gives us significantly better capabilities for any particular level of capital investment in a (virtuous?) positive feedback loop.
...), they should have a significant failure rate here. OTOH, hard drive failures are fairly common which is why I get the extended warranties for them, not the SSD's. Anecdotal evidence, but evidence nonetheless.
I've been using SSD's since the first generation and I like them. Each generation is cheaper, more capable, and more reliable, not that I've ever had one fail (knock on wood) despite using refurbished drives for my throw-away scratch. And given that they are used in a scratch configuration (VM's from golden images, large/big data,
"[I]t is a wise man who admits the limits of his knowledge or skill, and that pretending either causes harm." --Terry Go