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?"
If you're not good enough at arithmetic to understand that this isn't an issue, should you really be developing software?
I've had this sig for three days.
I'm using the Intel SSD and I think it's great - fast and silent. Will it last? I'd argue you never know about any particular model of hard drive or SSD until a few years after it is released. On the other hand, I'd also argue it doesn't matter much. Say one drive has a 3% failure rate in the 3rd year and another has a 6% rate. That's a huge difference percentage-wise (100% increase). And yet it's only a 3% extra risk - and, most importantly, you need a backup either way.
Do you have a swap file/partition? You're talking hundreds of writes a day, tops. That sounds like a big number, but in reality it just ain't. I would question why you feel the need for an SSD, though. I know the difference between $300 and $50 isn't that big in the grand scheme of things, what benefit are you expecting?
Whale
Does anyone know when the Sandisk SSD G3 are coming out?
Democrats or Republicans. They are both taking us to the same place and they are not afraid of us anymore.
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 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
The Raven
If you're worried about losing work, I think your backup solution is what you need to improve instead.
could a raid structure give the performance boost i assume you are after? ive no experiance with them but i gather they can offer higher read/write rates. Can someone with more experiance say exactly how much of a performace boost they give, a set of small HDD's could be the same price without the concerns over cycle limits
I'm not sure you will be able to take advantage of the best of the speeds for an external drive. Won't your interface be the limiting factor?
Probably better to buy more RAM.
Good luck with that though.
We actually just had a DNS appliance go south on us because the flash-card used went bad (older, non-SLC flash). We suffered complete data loss on the card with major I/O errors to the point where linux would not recognize it as a hdX or sdX. Having a couple sectors on a hard drive go bad can be a pain, but at least you can recover some data. On the other hand, it had been running for several years, so I would recommend that if you plan on using an SSD, try to trade it in or upgrade it on a regular basis to avoid this because when they fail, they FAIL!
You should get an SATA SSD instead.
Give me Classic Slashdot or give me death!
Yes, a SSD can be used for development.
A better question to ask is should you use a SSD for development.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Would be 2 overclocked ATI HD4870s in crossfire mode.
That's my story and I'm sticking to it.
I have been using my Thinkpad X300 for developing for the last several month without any problems !
Current SSDs have a lifetime of somewhere around 10.000 years. I think that's enough.
Since you're asking about it and mentioning revision control up front, I'm going to assume that you'll be committing your changes frequently to the revision control system.
If thats the case, you've already got a backup system in place to deal with hard disk failures thats probably better than any other solution for a workstation. Not only do you get backups of your source, you get (assuming your commits are good) nice checkpoints of working code rather than a backup of some random stuff you were working on and don't recall EXACTLY what your thoughts were during that backup.
My revision control system is my backup for my development machine. I commit (with comments) many times a day, the automated backups only run once a night and have no comments.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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 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.
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.
I couldn't help but notice, that you said several times per day, rather than several times per second.
Are you worried that after you die of old age, in the unlikely event that your great grandkids start to have problems with their inherited flash drive, they won't be able to replace it?
"Believe me!" -- Donald Trump
hey, if your boss is paying for it, buy a couple and replace them when they wear out
(or just tell him you'll need a better, bigger, faster one in a year)
Something that'll handle 30+Gb of RAM. Then it pretty much doesn't matter.
Deleted
Is disk access time really the limiting factor for development time? I'd suggest what you really need is heaps of RAM and a big disk cache.
The primary advantage of an SSD is that it's cool. This is a good enough reason to buy any piece of tech but the thing will possibly wear out in a year or so, which will probably outweigh the cool factor.
I find that a large part of my programming experience deals with VM images.
SSD's kick serious butt for VM's. So if you're a serious programmer that works with multiple environments - go for the performance and just back your stuff up daily.
You do back up your work, don't you? You know, in case it's lost, stolen, destroyed, etc.? An SSD going bad is hardly the only danger. So why not try out an SSD, and if you're especially worried, backup more frequently and keep more backups?
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
I'm not completely sold on using SSD for development (yet) as well because of the write-cycle problem but do think that the consumer SSD device in the near future will eliminate the write wear. If you must use a solid state device, I'd suggest getting one that is much larger than the projected development size and has better write cycle/wear numbers to help alleviate any premature data loss. I primarily use SSD's for backups. Any Apple Developers on a MacBook Air out there?
Life==Jeopardy. All the answers are right in front us - the hard part is coming up with the correct question.
LOL. On the plus side, you can only get herpes once :)
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.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
It really depends upon the size of the sutff you are doing. If you are going to recompile the same stuff over and over and the dataset will fit in memory... you most likely will get little to no benefit. Linux (Vista and others) cache every single file until some app needs memory and pushes it out. It sounds like he's doing it on a box by himself (not a server shared by 5000 other people), and with memory so cheap... unless you are compiling something huge I'd guess that you probably not have to disk again after the first time it read it in (as long as there isn't another app ran that eats up all the memory, forcing out cached files from buffer cache and at some point freed up all the memory again and the compile is ran again).
For a point app for a single user, spending less on SSD and buying more memory would probably give you much more benefits.
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.
Don't thank God, thank a doctor!
Take your local storage zpool and add the SSD as a cache device.
# zpool add (pool-name) cache (device path)
If price isn't an option, then he should get himself 4 ANS-9010's and set them up as a hardware RAID0 hanging off the back of good fast raid controller.
If he filled each of them with 4GB DIMMs he'd have 128GB of storage space.
Volatile? Hell yeah... But also just crazy fast...
Yes Francis, the world has gone crazy.
Now find a hard disk that'll last that long.
extern warranty;
main()
{
(void)warranty;
}
Only for porn, move along.
If your boss is willing to shell out for one, then go for it. If you actually do the math on the write limit, you'll find that you'll be dead of old age long before the drive runs out of writes in any given cell (Last time I checked it was something like 160 years of constant writes.)
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Can't you just load up on RAM and create a RAM drive for working stuff and keep the slow HDD for shutdown time ? Cheaper than SSD and no write cycle issues. You can also get RAM based IDE and SATA drives.
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
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.
Save your wrists today - switch to Dvorak
Not to be negative, but there's also no guarantee that she hasn't caught other new and exciting bugs in the time since you've last encountered her.
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.
There are very precise wear-leveling algorithms behind the scenes that take care of the fact that any one cell can only handle so many cycles. And on that note, technically, you count a cycle when the cell is erased, not written (though most writes mandate an erasure). It follows that SSDs offer predictable failure (firmwares don't tell you this, however, because in practice you will replace any SSD drive long before you approach the limit of erase cycles, even for MLC drives).
The reason MLC drives offer so many fewer cycles is right there in the name. There are multiple bits stored within a single cell, and to erase any one bit, you need to erase the entire cell.
This was on ant, but I think they're fairly applicable elsewhere:
1) Making the build less object oriented. Code reuse is not as important as speed in a build. Try to limit the creep of including all sorts of build task libraries.
2) Map your build and dist directories to a tmpfs.
I halved our build time just with these two steps.
SLC can handle millions of write cycles; and it's fast. With modern wear-leveling, you could erase and re-write to an SLC drive at maximum speed continuously for years before you would hit the maximum write cycle cap.
The best one at present appears to be the Intel X25-E, which is a whopping $800 street price for the largest 64 GB model. If that isn't large enough, then yo'll have to wait for the 128 GB model.
Intel's X25-M MLC model claims to have way better wear leveling algorithms than most MLC drives; and has demonstratedly better read and write performance than pretty much all other MLC drives; and is available at 160 GB. Even it had a predicted lifespan longer than most rotating drives.
Another non-functioning site was "uncertainty.microsoft.com."
The purpose of that site was not known.
Just to float an idea, why not do it like this:
- Build a computer with flash storage and lots of RAM
- Use RAM to store the code and data you're using for development
- Write commits to flash
- Write to flash occasionally to prevent data loss
Flash drives may be faster than disks, but RAM is still _much_ faster. An extra 4 or 8 GB of RAM doesn't cost that much, and is probably enough to hold the code and some test data for most projects. If you spend a lot of time compiling, you'll probably recover the cost of the RAM in no time, thanks to increased developer productivity.
Please correct me if I got my facts wrong.
I've been developing iPhone apps on my 15" SSD MacBook Pro since they were released in September-ish? The SSD is awesome-fast compared to normal laptop HDDs. I have a friend who installed his own SSD before Apple was selling them as a BTO and his is still running fine, too. You'll likely upgrade before you hit any SSD writing limits anyway. It's not something I'm even remotely worried about. If the drive does happen to fail, that's what AppleCare and backups are for. :)
Hexy - a strategy game for iPhone/iPod Touch
Then forget the SSD drive, unless you are worried about head crashing during a fall. Get yourself a 4+ bay ESATA enclosure and do a Raid 1+0. You will pin the bus for throughput and have fault tolerance out the wazoo. I would recommend larger drives, simply for the larger outer tracks (Larger, meaning high density, not necessarily greatest total capacity).
http://www.theinquirer.net/inquirer/news/293/1051293/ocz-1tb-ssd-raid-module
If you're out for performance, this could be very interesting.
EOM
No man, but they do make dandy soap holders.
yet, but I am eager to learn. What happens if you exceed the limit of writes? How does usage degrade the disks? Is heat bad? Does using the SSD as virtual memory degrade the disk fast?
What about bad sectors, how do they compare with HDDs? Are SSDs generally more sturdy(longer lifespans) than HDDs?
Inquiring minds want to know.
Knowledge is power. Knowledge shared is power lost.
They could be using random positions to write to, but more likely it is sequential and on a loop.
The first block is the one guaranteed for a number of erase write cycles.
System files will probably not change as often as your project files and the loop will happen over the available space as you erase, truncate or add to your project files.
The first failure will happen on a block in the available space, and the available space will tend to have more cycles (wear) than the system space.
So, one trick is to flip the system every now and again and help out the wear levelling yourself.
You can zap a block quite easily, by just filling up the available space and then just repeatedly erasing and writing to one block. It wouldn't be wise to do that to the boot sector though.
RAID can increase throughput, but it can't reduce access latencies.
Prefetch can. If you keep your project on a loopback file system smaller than RAM, the disk cache makes read latencies tend toward negligible.
Of course, if you can read two different things at the same time
Which requires a build tool that can multitask. Fortunately, GNU Make can: make -j2 tells Make to build two files at once if the dependency graph allows. In my experience, the number of simultaneous jobs should generally be the number of cores plus the number of spindles (e.g. 6 for a dual-core with a RAID 10 or a quad-core with a RAID 1), so that each CPU and each disk has something to do if possible.
However, suppose I fill up the drive with data, then free half of it. My question is: how does the drive know that half its sectors are free again for use in wear leveling? As far as the drive knows, all of its sectors still hold data from when the drive was full, and no sectors are available for levelling purposes.
Is there some protocol for telling the drive that "sectors x, y, z are now free"? Or does the drive itself understand the disk layout of the zillions of different filesystems out there?
Everyone's going SSD-crazy, but I'm not yet convinced. They're not _that_ much faster than spinning platters of death, at least not yet, and I'd much rather throw a ton of Ram at the disk cache for the same amount of money.
If you're really worried about performance, invest in a true Ramdisk - the kind that has DDR memory slots on one side and a SATA connector on the other. You can write a 2-line script to mount and format it on boot, and even backup its contents upon shutdown (if needed). That's the ultimate /tmp drive, and it will not wear out no matter how hard you pound it.
-Billco, Fnarg.com
Why would you worry about doing software development when filesystem journals and superblocks are likely to be written far more frequently (generally without ever relocating, which file blocks could do from time to time). This is why write-leveling algorithms exist. If drives (and/or filesystems) didn't perform write-leveling, they would be largely impractical for R/W for this reason.
Yes.
Serious Long-Term Fragmentation Problems...
Potential buyers BEWARE, and do some research first. Google the term "intel ssd fragmentation" before purchasing this drive to understand this potential long-term issue. Chances are it won't impact most people, but if you plan on using this drive to house lots of smaller files, think again.
Also
Absolutely avoid using defragmentation tools on this drive! They will only decrease the life of the drive.
I primarily use SSD's for backups.
Yeah, I primarily use my Learjet as a backup in case my civic breaks down too.
Its rated for 15 MB/s - not exactly a screamer, but it sure makes my AV run faster on ZIP files, and minimized disk fragmentation on C:
It hosts 2GB of swap space, TMP and TEMP.
150 odd comments about "SSDs", and not a single bad Star Wars joke? Very disappointing. Here I'll start...
Use SSDs for software development? Why, I'd think you could use a super star destroyer for just about anything you wanted to.
Ba dum ching.
"Mind, as manifested by the capacity to make choices, is to some extent present in every electron." -Freeman Dyson
Since there are no moving parts, there is no difference in latency for reading different sectors. This is the reason you simply don't care about fragmentation. Regarding limitations on lifespan, there are many systems using SSD for databases indexes, where the index is updated hundredth times a day and the drive is specified to work for several years.
from personal experience, the build process is limited by I/O capabilities, and this is where the SSD is just way beyond any mechanical disk. Real life performance information give about 100 IOPS for Fiber channel / SAS disks, and 80 IOPS for SATA disks. for SSD the numbers go up to 5,000 IOPS - about 50 times increase.
design to last - blog on system engineering
Odd that no one suggested this yet, but you could keep your current HDD as a working area, and install the OS (and programs) on the SSD. I have been thinking about doing something like this in the past few weeks. I have no direct experience but, browsing forums, it seems a popular layout.
On Linux, you would install / on the SSD, then mount /var and /home on two HDD partitions; on Windows I suppose that you would place C: on the SSD and put a link from C:\...\Documents and Settings to D:, the HDD.
This way, you get lots of storage in your home folder (where you need it), and you can write, delete, rewrite as usual; plus, you get fast system and application start-up, because those files are on the SSD, where you do not write as often but where you also like things to go a bit faster. You can also get away with a ludicrously tiny SSD (e.g. 16 GB for Ubuntu system files are waaay more than enough: at my place / is 6 GB, of which /var is already 1.4GB), so you can invest on speed rather than capacity.
As someone already suggested, working on a SSD may make you write I/O intensive software that will not fare as well when you run the program on a HDD; but if you have your SVN checkout and your build on a HDD, you will not risk this error to begin with. In any case, most read/write-intensive file operations on user partitions are sequential (storing backups, playing MP3s or movies...), and HDDs are still quite fast on sequential files (assuming no or negligible fragmentation, granted).
Victims of 9/11: <3000. Traffic in the US: >30,000/y
I'm curious to know what type of day to day development would gain benefit from flash over just getting some more ram since it seems the files are stored locally anyway instead of being on a shared resource.
Math class is tough. Want to go shopping? Okay, meet me at the mall!.
They sure can, but it doesn't make debugging any easier.
I lolled a little at this. In my pants. I know I shouldn't but I couldn't help it.
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
I don't know who this "The Flash" is...
http://lmgtfy.com/?q=%22The+Flash%22
"But this reminds me of some odd invoices I've seen here lately at Star Labs."
Crap. Let me try that again.
"But this reminds me of some odd invoices I've seen here lately at Star Labs."
Bow-ties are cool.
Theres a lot of talk here about the statistics on SSD being better than HD, but a well tuned system with a lot of RAM (lot == >= 4GB) hardly ever goes to disk except on writes. One can fine tune the write activity in various ways, or use system level tools like dtrace or ktrace or kprobes to look at what is really happening. I know Linux does a good job, but it has a long way to go .. still.
I do development on embedded devices where the code is stored in flash. During the development, we would typically download code to the test devices dozens of times a day (obviously with no wear leveling) over a year or two. Haven't seen any problems with dead flashes yet. Maybe we will see failures after a few more years, but if any development took that long then I'm sure we could afford to throw away the test device and build another one!
Your mileage may vary with an SSD drive, but if you have enough RAM to avoid too much swapping, then you should be able to get a couple of years use out of it, and probably a lot more.
http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3403
They showed that the non-Intel MLC drives can have some serious performance issues, so I'de stick with an Intel MLC. If designed correctly, an SSD is actually more reliable than a standard HD, since you know exctly when it's going to fail. Here's some key points from the article on reliability:
page 4: OEMs wanted assurances that a user could write 20GB of data per day to these drives and still have them last, guaranteed, for five years. ... Intel went one step further and delivered 5x what the OEMs requested. Thus Intel will guarantee that you can write 100GB of data to one of its MLC SSDs every day, for the next five years, and your data will remain intact.
Intel actually includes additional space on the drive, on the order of 7.5 - 8% more (6 - 6.4GB on an 80GB drive) specifically for reliability purposes. If you start running out of good blocks to write to (nearing the end of your drive's lifespan), the SSD will write to this additional space on the drive.
page 5: Intel's SSDs are designed so that when they fail, they attempt to fail on the next erase - so you don't lose data. If the drive can't fail on the next erase, it'll fail on the next program - again, so you don't lose existing data. You'll try and save a file and you'll get an error from the OS saying that the write couldn't be completed. The beauty here is that the SSD knows exactly when it can't erase/program a block, and if the drive knows, then you can use software to ask the drive what it knows. In the near future Intel will be releasing its own SSD tool that will let you query two SMART attributes on the drive: one telling you how close you are to the rated cycling limit, and one telling you when you've run out of reallocating blocks. The latter is the most important because Intel fully expects these drives to outlast their rated limits. As bad blocks develop, the SSD will mark them as such and write to new ones - by telling you when it has run out of bad blocks (or nearly run out of bad blocks), you'll know exactly when you need a new hard drive.
I have been using Netbeans on my Eee from time to time, and it is actually starting much faster than on my "big" and powerful laptop. SSD is def. great thing for developers, as all IDEs and most programming tools rely on multiple small-size files. Wether it's parser, linker, compiler, interpreter or documentation generator - it'll be quicker because it can reach different small files with no delay.
On the other hand if you do sequential reads like editing big files of videos/audio/graphics, a good HDD will do the work.
If your main problem is speeding up your development environment's use of temporary disk storage (because Linux is already caching a lot), use /tmpfs, which stores the files in virtual memory, and if the system needs to page them out, it does that - it's really useful for files that are going to get created for short periods but don't need to get kept for long.
Windows Vista Readyboost is doing something fancy and semi-automatic with caching in USB flash disks - get yourself a USB2 memory stick and turn it on. The stuff is so cheap these days that you might as well buy a large fast ReadyBoost stick, but you'll probably get a lot of payoff even from adding small drives - 8GB is now $20-40, and 32GB is ~$60-120 depending on how extreme you want to get.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Then just create a RAM drive and check out the code into that cache when you want to work on it. I use tmpfs and put the cache for my firefox browser into /tmp on my Eee 4G for that very reason.
Yeah, you might get faster performance if you spend twice as much money to get SLC instead of MLC, and you may want to do that, but as far as write counts go, the stuff is so cheap you Just Don't Care\(tm. Suppose a $20 8GB USB stick burns out in a year - you've wasted more money than that reading this Slashdot discussion, and if it saves you a few hours a month you win, and when it's burned out you'll have to spend $10 replacing it with 16-32GB.
If you're doing something like Vista ReadyBoost, a $10 couple of gigabytes will let Vista do some decent caching, plus it'll cache your development tools and frequently used files (in case RAM wasn't doing that adequately) on one non-rotating spindle so the rotating disk can spend all its time supporting the files that are actually changing and therefore spend a lot less seek time.
If you're using Linux, you could use it for /tmp (if you're not using /tmpfs) or if it's fast enough flash you could probably even get away with using it for swap, or there's probably some appropriate fancy union filesystem thing you can do which will let you keep the more frequently used bits of your environment on flash and the less-used bits on rotating disk.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Duhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh.
Look, it's time to start filtering stupid question from /. or I'm going to unbookmark it.
I find the contributions of Anonymous Coward to be most valuable. I can't imagine that anyone exists who thinks otherwise. /. and certainly to all its users if he were to unbookmark /. /. as well should Anonymous Coward disappear, as will probably half the /. population.
/. user
It will be a big lose to
I for one will unbookmark
Best Regards,
A very concerned
ps: Power Point is hard, Let's use notepad
You speak London? I speak London very best.
I've been using a Patriot Warp V2 64GB SSD for a relatively large project (~400k lines of C code).
The "write stutter" is a bit annoying, especially when I do a full "make clean", but it's not too bad.
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
I tried this about a year ago with a mid-range disc-on-module device. For most purposes it worked well, and I use DOM in several of my servers now, but not in what was then my development machine. Subversion was one of the reasons - it was slower by more than a factor of two - but I could probably have lived with that. Much more serious was the effect on build times, which was not as large but happens much more often. Extrapolating from my results I suspect that the Intel X25-M or similar would probably be OK, in the sense of not being worse than a conventional hard drive, but I've not tested it yet.
I use MLC SSDs for development for a long time now, and I have no hard disks at all. I am very happy and I have had no problems. I also prefer MLCs over SLCs because I prefer to replace them and upgrade often than to keep an SSD for too long.
I've seen many people offering their experience, which is good, but this is spinning off into a variety of arguments. As far as I can understand, the original question was: Are SSDs suitable for development?
I would say the most important thing to remember in this case is: you get what you pay for. And in this case, the cost-benefit analysis may not be worth it over, say a regular 10k or 15k rpm disk (or array), or perhaps a nifty "hybrid SSD" like the one in the MSI netbook? It's (usually) a 2.5" SATA disk with a smaller SSD "buffer" - giving better IOPS with less of a price hike (and write issues).
If you are ok with paying on the order of $600+ for a single drive, check out DRAM Flash technologies - doesn't get much faster than using memory as disk! But realistically, I'd say stick with fast (and cheap) regular disks for now - maybe store some frequently read, but not often edited files on a small test SSD to try it out first.
And if you do decide to invest in some sort of SSD or hybrid, I would recommend going with one that uses either Samsung or Intel chips.
Please keep hands and feet inside the Internet at all times.
Well, the important thing to know with this, you won't be wearing the same 10-30%. Even if you update the "same" files over and over, the wear-leveling will move those "same" blocks for that file each time you write them... you will still be wearing the SSD evenly, not wearing out some hot spot while the rest of the disk is pristine.
Several times a day? That's nothing. Make sure you don't put (heavily-used) swap on there and I think it'll be hopelessly obsolete before it wears out.
Wouldn't [a ramdisk] give most of the same benefits, if the ramdisk is big enough to contain the files you use to compile?
Sure it would, but then you'd have to copy over your files every time you boot up, and you wouldn't have the safety of persistence if the power goes out.
Unless you create a RAID-1 with a RAM disk and a loopback file system. That would act like a big-ass dedicated disk cache as long as you can get all the reads to go to the RAM disk.
you still have the problem of filling that cache... i.e., you still have to load the files from a hard drive at some point to even fill the cache.
Cache designers call this situation a "compulsory miss", and the common workaround for compulsory misses is to hide them with prefetching. Have a background thread load all the files on which the current file depends.
Short stroking will help speed up development, and without the write cycle issues of flash. It's also much cheaper.
You realize that because the seek time on SSDs is the same regardless of the seek involved that fragmentation is not really an issue, right?
Reading the block after the one you are currently reading takes the same amount of time as reading the first block on the disk followed by the last block on the disk.
Fragmentation is irrelevant, and because it is irrelevant you can get by with wear leveling technologies that place data scattered all over the disk without worrying about its relationship to other data.
Okay, so its a bit more complex than that, but the point is that regardless where the data is physically stored on the device, it gets returned at the same rate.
Just think of an SSD as a slower and persistent form of RAM. Does your RAM getting 'fragmented' make your applications slower? No, at least not directly, it can make the allocator take a more time, but thats due to the allocator itself, not because it takes longer to read block 0 followed by block 25 than it does to read block 1 right after 0.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager