Slashdot Mirror
Can SSDs Be Used For Software Development?
hackingbear writes "I'm considering buying a current-generation SSD to replace my external hard disk drive for use in my day-to-day software development, especially to boost the IDE's performance. Size is not a great concern: 120GB is enough for me. Price is not much of a concern either, as my boss will pay. I do have concerns on the limitations of write cycles as well as write speeds. As I understand, the current SSDs overcome it by heuristically placing the writes randomly. That would be good enough for regular users, but in software development, one may have to update 10-30% of the source files from Subversion and recompile the whole project, several times a day. I wonder how SSDs will do in this usage pattern. What's your experience developing on SSDs?"
Unless you type like The Flash, even MLC SSDs from the better vendors (Intel) should be fine for anything outside of server applications. Simple math should back this up (how many GB total the drive can write over its lifetime vs how much you produce each day). merlin
If you're worried about losing work, I think your backup solution is what you need to improve instead.
The main difference is a good SSD is much, much faster than any hard drive. If discussions about the topic don't give that impression, it's only because people fixate on sustained transfer - where there is still some competition between slower SSDs and hard drives - rather than seek time, which is often more important, and where SSDs blow the doors off hard drives. To me, suddenly widening the biggest bottleneck in PC performance for the first time in a couple decades is pretty exciting.
The company I'm working at thought about using SSDs, but we were thinking more on the server end (to allow faster database access.) You don't have to worry about the write limits as it's highly unlikely you will hit them within the lifetime of a standard hard drive.
The main issue we ran into was cost, the drives we were looking at started around $3,000 for something like 80 gigs. That just wasn't worth it for us, though if you personally feel that the added cost (and I doubt you're looking at a $3,000 SSD, more likely you're looking at the $300 drives) is worth the performance gains then go for it. Though I think even for $300 it won't make a worthwhile difference.
There are other bottlenecks to consider, is your CPU fast enough, do you have enough RAM, could the hard drive your software and OS is on use an upgrade, etc. Perhaps even buy an internal SATA drive (if you can) to replace the external you're using, those external enclosures generally aren't known for their performance. If you've exhausted all of those options and you still need more speed, then I'd say go for the SSD.
Yeah, except only the SLC SSDs are worth having. MLC SSDs are junk and extremely common, you're better off with a spinning platter drive. However, I can't recommend SLC SSDs enough, they're substantially faster than conventional spinning platter drives in all ways.
Game! - Where the stick is mightier than the sword!
LOL. On the plus side, you can only get herpes once :)
Although they use an SSD for another purpose, they said currently SSD's last about 6 months under heavy read/write conditions (cache on a RAID controller) even with leveling techniques. Hard drives last a whole lot longer for those purposes I would say.
I think SSD in a desktop-type system would be all right however I would suggest you invest in some fast disks instead of SSD until SSD matures and more lifetime data is available. Remember MTBF doesn't always mean that a piece of hardware will last that long. Most likely it will die long before that.
Custom electronics and digital signage for your business: www.evcircuits.com
Developing on a conventional SSD with large user-visible erase blocks is PAINFUL. The small writes caused by creating temporary files in the build process absolutely destroy performance. There are ludicrously expensive enterprise products which work around this in software, but at the laptop/desktop scale, you want something that's self-contained. As far as I'm aware, Intel's X25 drives are the only ones actually on the market now that hide the erase blocks effectively at the firmware level. The MLC ones should be fine.
There's no failure quite as dissatisfying as a complete and total solution to the wrong problem.
Cheaper drives (which mgmt is sure to require) have 1,000 write cycles (assuming the worst). For certain high-traffic files, that means (assuming 30 writes in a day) a whole 33 days of use.
If that were true. Then an SSD hard drive couldn't run a linux mail server for a small business for more than a couple minutes thanks to the various log files.
1) The maximum write cycles for a block was around 10,000 in 1994. And about 100,000 in 1997. But in 2009 you think 1000? No. Its currently in the millions, even for the cheap SSDs.
2) Look up wear levelling.
3) Look up the MTBF on an SSD vs a spinning platters type.
I've seen studies that have calculated that modern drives will could write continuously at maximum speed for 50+ years before exhausting wear levelling and hitting write cycle limits.
The odds of it failing from something else long before then are much greater. Getting a mere 5+ years of life and easily beating your average spinning disk hard drive is a no brainer.
NTFS has a fairly high overhead for a compile, lots of small temp files that all have to be created and deleted having their ACL's added to the MFT and then removed. I've seen compile time drop to 1/4th the time by switching from NTFS to FAT32 on the same hardware.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
I Have the 80 gig MLC SSD from intel, and it's not junk. It's freaking fast.
That way it'll encourage them to write efficient implementations.
Actually, the opposite is true.
If development is painful (which it is, if your workflow is hampered by slow builds), you will produce crappier code. It's all about retaining focus & flow. Sad thing is, compilation still takes too long; you can still check your gmail or refresh slashdot.
How many of you are reading this article while automake is checking the version of your fortran compiler in order to run gcc on a .c file?
Save your wrists today - switch to Dvorak
The whole "millions" thing may be true for SLC parts. MLC parts (which are much cheaper) have much lower write counts. The best MLC flash I'm aware of is only rated for a million write cycles. Thousands or tens of thousands is more typical for MLC flash parts. Write amplification makes this even more fun, since it means that a write of one disk block can require rewriting many, many blocks that otherwise would not have been written. If the wear leveling algorithm is optimal, then it's a moot point. If the wear leveling is nowhere near optimal, you can create artificial workloads that will burn out a few cells on the flash part in hours, which is a bit problematic. There is no clear-cut answer for this sort of question, unfortunately, at least not with the current crop of MLC tech.
Consider a log-structured filesystem, perhaps....
Check out my sci-fi/humor trilogy at PatriotsBooks.
It's also far from cheap.
If you build is really IOPS-bound, then an SSD will utterly smoke a single disk. Even a whopping great expensive disk can only muster 300 iops under the best possible circumstances, and typically 100 iops under real conditions. A cheapo SSD can deliver 1000 mixed iops, and a good SSD can deliver 100,000 mixed iops. Ever since switching to an SSD on my dev machine I no longer have to suffer through things like a :wq in vim taking 5-10 seconds, or loading a file taking several seconds, etc. One of the benchmarks I did was starting Firefox during a build. On the machine with a disk, it actually took more than ONE MINUTE to start Firefox under a build load. With the SSD, there is no measurable difference between the Firefox startup on an idle machine and a machine with a build happening. The difference is massive.
If you are relying on case sensitivity to differentiate files that's a big old bag of fail. NTFS is case preserving but will not allow the same filename with different cases, there are plenty of protocols and code that are either case preserving or case blind so you should never really rely on it for much of anything but your own neumonic of sorts.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Warning: I'm an Intel employee
But I've been using the 80GB Intel MLC drive since mid-year 2008 and it's great. Very fast and silent -- I refuse to go back to a mechanical drive again. It's perfect for a client workload (99.9% of users) but not perfect for a transaction heavy server (use the SLC drive).
My workload is writing code and generating/parsing very large data sets from fab (1 - 4 GB).
Here is the "insider" information from my drive:
6.3TB written total (roughly 9 months of usage)
58 cycles (average) on each block of Nand
Given that the component Nand is qualified out to 10K, that's clearly long enough for at least 5 years of usage
PPT is hard. Let's yell.
My own experience with a pair of Intel X25-M SLC 32GB drives: after less than a month of moderate use one began reporting unrecoverable read errors at an increasing rate.
We have RMAed the drive and gotten a replacement, but based on the approximately 1500 hours real-world MTBF we had to that point, instead of the claimed 3 million hours MTBF/1 petabyte write lifetime, and unrecoverable bit read error rate on the order of 1/10^15 which lured us into having to repair the resulting database damage.
with high read/write rates (speed and cycles) you need an SLC type SSD, avoid the MLCs for enterprise purposes as they are not as reliable by design, though many now have ECC features built in..
you will pay a premium for the SLC drives.
Some of the other options offered are very viable ways to do what you are trying for, most notably the ramdrive option, if storage volatility is not a problem.
If it is, then (money no object) i'd go with a SATA SLC-SSD RAID5 array..
or in the same vein but cheaping out, just a SATA SLC-SSD
the following site has a ton of good comparison info of different SSDs and their speeds
http://www.storagesearch.com/ssd-buyers-guide.html