Slashdot Log In
Can SSDs Be Used For Software Development?
Posted by
timothy
on Fri Mar 06, 2009 03:20 PM
from the real-world-odds dept.
from the real-world-odds dept.
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?"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
I'm not seating it (Score:5, Insightful)
Re:I'm not seating it (Score:5, Interesting)
The real key here is this: when an SSD drive can no longer execute a write - the disk you will let you know. Reads do not cause appreciable wear so you will end up with a read only disk when the drive has reached the end of it's life. This is vastly superior to the drive just dying becuase it's had enough of this cruel world.
I'd be interested to see some statistics on electrical failure of these drives though... but it seems that isn't as much of an issue.
Parent
Re:I'm not seating it (Score:4, Insightful)
"Anyway, the make believe part is your thinking that by failing a write then your data is still readable which in fact majority of cases its dead Jim"
Are you sure about this - based on your previous flow:
"4) Chip reports back to controller erase success or fail"
is when the OS is notified by the drive that the write failed. Presumably, the drive or the OS might try another part of the bank, sector or what have you. At no point are you earsing non-free sectors.
It is fundamentally the write operation that causes the bits to fail, not the read. So the rest of the contents of the disk are fine - make an image and transfer to a new drive. Easy.
Parent
Re:I'm not seating it (Score:5, Insightful)
"Anecdotal evidence" is an oxymoron.
Point is, I could just as easily claim that SSDs last ten years, and since neither of us has provided a shred of evidence to support our assertions, neither of us has any credibility whatsoever.
Parent
Re:I'm not seating it (Score:4, Funny)
"Anecdotal evidence" is an oxymoron.
Do you have any evidence?
Parent
Re:I'm not seating it (Score:5, Interesting)
So interested people want to know --- how do you get the "insider" information from an X25-M (ie., total amount of writes written, and number of cycles for each block of NAND)?
I've added this capability to ext4, and on my brand-spanking new X25-M (paid for out of my own pocket because Intel was to cheap to give one to the ext4 developer :-), I have:
/sys/fs/ext4/dm-0/lifetime_write_kbytes
<tytso@closure> {/usr/projects/e2fsprogs/e2fsprogs} [maint]
568% cat
51960208
Or just about 50GB written to the disk (I also have a /boot partition which has about half a GB of writes to it).
But it would be nice to be able to get the real information straight from the horse's mouth.
Parent
Swap? (Score:4, Interesting)
Re:Swap? (Score:5, Informative)
Parent
Re:Swap? (Score:4, Informative)
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.
Parent
Re:Swap? (Score:5, Insightful)
Parent
Re:Swap? (Score:5, Informative)
Parent
Re:Swap? (Score:5, Funny)
Or using Java/Haskell/Ruby and/or Eclipse/VS.NET/Emacs (delete according to prejudice).
Parent
should be fine (Score:3, Informative)
Re:should be fine (Score:5, Funny)
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).
I don't know who this "The Flash" is... But this reminds me of some odd invoices I've seen here lately at Star Labs. Someone special-ordered a custom keyboard rated to one hundred times the usual keystroke impact, an 80MHz keyboard controller, and a built-in 1MiB keystroke buffer. Pretty ridiculous, huh? The usual 10ms polling rate for a USB keyboard should be enough for anybody - no need for all that fancy junk.
Parent
Re: (Score:3, Insightful)
how many GB total the drive can write over its lifetime vs how much you produce each day
It's not as simple as that. Make a small change (insertion or deletion) near the beginning of a large source code file, and the entire file – from the edit onward – must be written over. Then, any source code file that has been modified must be read and built, overwriting the previous binary files for those source codes. Finally, all the binary files must be re-linked into the executable.
So you're not just writing ___ bytes of code. You're writing ___ bytes of code, re-writing ___ bytes of code
Get an enterprise drive (SLC, not MLC) (Score:5, Insightful)
If they're good enough for Databases (frequent writes), they should be just fine for devel.
OTOH, You should be a lot more concerned about losing data because of a) software bugs or b) mechanical failures in a conventional drive
Backups (Score:5, Informative)
If you're worried about losing work, I think your backup solution is what you need to improve instead.
How do raids perform? (Score:3, Interesting)
IDE? (Score:5, Funny)
You should get an SATA SSD instead.
SSDs = productivity (Score:5, Interesting)
I use SSDs for my (both) development systems--the first was for the work system, and after seeing the improvements I decided I would never use spinning-platter technology again.
The biggest performance gains are in my IDE (IntelliJ). My "normal" sized projects tend to link to hundreds of megs of JAR files, and the IDE is constantly performing inspections to validate the code is correct. No matter how fast the processor, you quickly become IO-bound as the computer struggles to parse through tens of thousands of classes. After upgrading to SSD, I no longer find the IDE struggling to keep up.
I ended up going with SSD after reading this suggestion [jexp.de] for increasing IDE performance. The general jist: the only way to improve the speed of your programming environment is to get rid of your file access latency.
Is it worth the money for you? (Score:4, Informative)
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.
Developers should use *slow* machines (Score:4, Insightful)
If you give your programmers an 8-way 4GHz m/b with 64GB of memory (if sucha thing exists yet), they'll use all the processing power in dumb, inefficient algorithms, just because the development time is reduced. While those of us in the real world have to get by on "normal" machines.
When we complain about poor performance, they just shrug and say "well it works fine on my nuclear-powered, warp-10, so-fast-it-can-travel-back-in-time" machine"
However, if they were made to develop the software on boxes that met the minimum recommended spec. for their operating system, they'd have to give some thought to making the code run efficiently. If it extended the development time and reduced the frequency of updates, well that wouldn't be a bad thing either.
Re:Developers should use *slow* machines (Score:4, Insightful)
Parent
Re:Developers should use *slow* machines (Score:5, Insightful)
Disagree. This problem went away for the most part.
First, performance isn't nearly the problem it used to be. We aren't using anymore the kind of hardware that needs the programmer to squeeze every last drop of performance out of it. In fact, we can afford to be massively wasteful by using languages like Perl and Python, and still get things done, because for most things, the CPU is more than fast enough.
Second, we're not coding as much in C anymore. In C I could see this argument, lazy programmer writing bubble sort or something dumb like that because for him waiting half a second on his hardware isn't such a problem. But most of this has been abstracted these days. Libraries, and high level languages contain highly optimized algorithms for sorting, searching and hashes. It's a rare need to have to code your own implementation of a basic data structure.
Third, the CPU is rarely the problem anymore, I/O is. Programs spend most of their time waiting for user input, the database, the network, or in rare cases, the hard disk. A lot of code written today is shinier versions of things written 20 years ago, and which would run perfectly fine on a 486. Also for web software the performance of the client is mostly meaningless, since heavy lifting is server-side.
Also, programming has a much higher resource requirement than running the result. People code on 8GB boxes because they want to: run the IDE, the application, the build process with make -j4, and multiple VMs for testing. On Windows you're going to want to test your app on XP and Vista, on Linux you may need to try multiple distributions. VMs are also extremely desirable for testing installers, as it's easy to forget to include necessary files.
I'd say that giving your developer a 32 core box would actually be an extremely good idea, because the multicore CPUs have massively caught on, but applications capable of taking advantage of them are few. Since coding threaded code is not lazy but actually takes effort, giving the programmers reasons to write it sounds like a very good idea to me.
Parent
Re:Developers should use *slow* machines (Score:5, Insightful)
That's just stupid - I'm going to write better code because my compiles take longer?
There seem to be a lot of these posts on Slashdot with down-home folk wisdom on how to educate the smug and indifferent programmer, who is so clearly divorced from reality that he doesn't even know what computers his customers use. I get the sneaking suspicion that the authors know very little about actual programming.
There are two reasons for bad software:
a) incompetent programmers
b) bad project management
The latter includes things like unrealistic timelines and ill defined scope and requirements. I'm not sure which one is the bigger culprit, but both are pervasive.
In neither case, though, are you going to fix the problem with gimmicky bullshit like inadequate equipment.
Parent
Re:Developers should use *slow* machines (Score:5, Informative)
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?
Parent
Re:Developers should use *slow* machines (Score:5, Insightful)
The argument was, if the snipers knew they couldn't fire again immediately, they would be more careful lining up and aiming that first shot. With an 'auto-loading' rifle, you could keep your eye in the scope and fire off more rounds.
It seems quite obvious, that if you're in the field, the seconds after that first shot are very important. If you need to take your eye away from the scope, and spend the time reloading the chamber, the outcome could be completely different than if you were able to fire off a few rounds immediately.
A good sniper would have aimed that first shot up carefully no matter what rifle they were using, in the same way a good programmer will make efficient, elegant algorithms no matter what machine they're using. You'd only have to 'limit' your programmers if you think they're bad programmers. If a supervisor is thinking along these lines, they've already hired bad programmers and are setting both themselves and their team up for failure. The faster the machines, the less time wasted. You don't need forced limits reminding them about efficiency, because any decent programmer will already be thinking about it.
Parent
Re:Developers should use *slow* machines (Score:4, Insightful)
The reality in any organization is that there are good programmers and not-so-good programmers. And from time to time, even the good ones make mistakes. Different programmers have different strengths and weaknesses. That is why programming languages have things like type checking, and why software developers employ principles like encapsulation and data hiding. Your argument is that these practices are "restricting" clever programmers by making the software inflexible.
Taking your argument to its logical conclusion, you might say it isn't necessary to add debugging information or logging to programs if you higher decent programmers who never make mistakes.
Parent
Re:Developers should use *slow* machines (Score:5, Insightful)
No, developers should develop on fast machines... and test on slow machines.
It's a waste of money to pay your programmers $50/hr to sit and wait for compiles to complete, IDEs to load, etc. That hurts the employer, and the additional cost gets passed on to the customer. It's in everyone's best interest that developers are maximally productive.
Give them fast development environments, and realistic test environments.
Parent
I've been doing just this (Score:5, Interesting)
Just got one in a Dell laptop, came with Ubuntu. A subjective overview:
I have no idea how well it performs with swap. I'm not even really sure why I have swap -- I don't have quite enough to suspend properly, but I also never seem to run out of my 4 gigs of RAM.
It's true, the write speed is slower. However, I also frequently transfer files over gigabit, and the bottleneck is not my SSD, it's this cheap Netgear switch, or possibly SSH -- I get about 30 megabytes per second either way.
So, is there gigabit between you and the SVN server? If so, you might run into speed issues. Maybe. Probably not.
Also worth mentioning: Pick a good filesystem if a lot of small files equals a lot of writes for you. A good example of this would be ReiserFS' tail packing -- make whatever "killer FS" jokes you like, it really isn't a bad filesystem. But any decent filesystem should at least be trying to pack writes together, and I only expect the situation to improve as filesystems are tuned with SSDs in mind.
It also boots noticeably faster than my last machine. This one is 2.5 ghz with 4 gigs of RAM; last one was 2.4 ghz with 2 gigs, so not much of a difference there. It becomes more obvious with actual use, like launching Firefox -- it's honestly hard to tell whether or not I've launched it before (and thus, it's already cached in my massive RAM) -- it's just as fast from a cold boot. The same is true of most things -- for another test, I just launched OpenOffice.org for the first time this boot, and it took about three seconds.
It's possible I've been out of the loop, and OO.o really has improved that much since I last used it, but that does look impressive to me.
Probably the biggest advantage is durability -- no moving parts to be jostled -- and silence. To see that in action, just pick out a passively-cooled netbook -- the thing makes absolutely no discernible noise once it's on, other than out of the speakers.
All around, I don't see much of a disadvantage. However, it may not be as much of an advantage as you expect. Quite a lot of things will now be CPU-bound, and there are even the annoying bits which seem to be wallclock-bound.
If you really want blistering performance... (Score:3, Insightful)
If he filled each of them with 4GB DIMMs he'd have 128GB of storage space.
Volatile? Hell yeah... But also just crazy fast...
Simple arithmetics (Score:5, Insightful)
Now find a hard disk that'll last that long.
RAM disk ? (Score:3, Interesting)
Adaptec confirms it... (Score:4, Informative)
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.
How about ramdisks? (Score:3, Interesting)
Sometimes I wonder whether it would make sense to optimize the disk usage for flash drives by writing transient files to ramdisk instead of hard disk. E.g. in compilation, intermediate files could well reside on ramdisk. If you rely on "make clean" a lot (e.g. when you are rebuilding "clean" .debs all the time), you won't have that much attachment to your object files.
Of course this may require more work than what it's really worth, but it's a thought.
Intel or bust (Score:3, Informative)
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.
Re:Umm... (Score:5, Funny)
Parent
Re: (Score:3, Funny)
I'd say: "Programming is hard let's do Java"
Re:Umm... (Score:5, Funny)
Parent
Re:Umm... (Score:5, Insightful)
If you're not good enough at arithmetic to understand that this isn't an issue, should you really be developing software?
Maybe you can explain why it isn't an issue, then?
One thing about flash in general is that in order to rewrite a small amount of data, you need to (at the low level) erase and rewrite a relatively large amount of data. So depending on how extensively the filesystem is cached, where the files are located, etc., rebuilding a medium-sized project could wind up re-writing a large portion of the SSD...
Parent
Re:Umm... (Score:5, Insightful)
Neither he nor you have attempted to answer the question quantitatively. Look at how big a block is, a bit about their write-leveling strategy, how large your source files are, the quantity of data you overwrite and how frequently, and what the lifetime of SSD blocks is, and figure out how long the SSD should last. Even an order-of-magnitude calculation would be better than nothing.
You both are approaching the problem qualitatively: SSDs have limited rewrite lifetimes, and I'm doing a lot of rewriting -- isn't that bad? You don't know! Figure it out!
Parent
Re:Umm... (Score:5, Interesting)
Before we start, let me make a prediction: You never asked about the MTBF of your hard disk, right...?
http://www.intel.com/design/flash/NAND/mainstream/ [intel.com]
a) When Intel says "new level of ... reliability", maybe it means they thought about this problem when they designed the drive.
b) When they say "NAND flash", maybe it means they're not using the cheapest MLC memory as mentioned in that scary wikipedia article.
c) When their datasheet says "Minimum useful life of five years, assuming 20Gb/day of writing", maybe they got those numbers from real engineers, with degrees.
d) When their datasheet also says, "Should the host system attempt to exceed 20 GB writes per day by a large margin for an extended period, the drive will enable the endurance management feature to adjust write performance, this feature enables the device to have, at a minimum, a five year useful life", maybe they were really really paranoid about saying 'five years' because they know people will start class-action lawsuits if it doesn't work out.
So, um, how this even got greenlighted in 2009 is beyond me. It's like 1999 called wanting its flash-myths thread back.
Parent
Re:Umm... (Score:5, Informative)
Parent
Re: (Score:3, Insightful)
Re:Umm... (Score:5, Insightful)
Parent
Re:Umm... (Score:5, Informative)
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.
Parent
Re:Umm... (Score:5, Informative)
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....
Parent
Re:Umm... (Score:4, Informative)
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.
Parent
Re:Lifetime is not an issue :p (Score:5, Funny)
Current SSDs have a lifetime of somewhere around 10.000 years. I think that's enough.
10000 years or 100000 writes, whichever comes first. :D
Parent
Re: (Score:3, Funny)