An SSD Endurance Experiment: They're All Dead (2015)
techreport.com
An SSD Endurance Experiment: They're All Dead (2015)
1–10 of 54 posts
Re: An SSD Endurance Experiment: They're All Dead (2015)
#2its nice when a tech article ends with a song
Re: An SSD Endurance Experiment: They're All Dead (2015)
#3Continuous Integration systems can really burn through SSD endurance. If you have a large, compiled code base which rebuilds on every checkin, you will be creating and deleting object code constantly. Use smartmontools or HDD Guardian to keep an eye on endurance.
Our code base creates around half a gig of compilation product on every build. We used up the endurance on a consumer-level Micron SSD in about a year. No data loss occurred.
Re: An SSD Endurance Experiment: They're All Dead (2015)
#4Continuous Integration systems can really burn through SSD endurance. If you have a large, compiled code base which rebuilds on every checkin, you will be creating and deleting object code constantly. Use smartmontools or HDD Guardian to keep an eye on endurance. Our code base creates around half a gig of compilation product on every build. We used up the endurance on a consumer-level Micron SSD in about a year. No d…
Maybe there's room for a 'file write filter' that avoids writing identical data back to the same file. To save SSD lifetime. Sounds like it would have application.
Re: An SSD Endurance Experiment: They're All Dead (2015)
#5Continuous Integration systems can really burn through SSD endurance. If you have a large, compiled code base which rebuilds on every checkin, you will be creating and deleting object code constantly. Use smartmontools or HDD Guardian to keep an eye on endurance. Our code base creates around half a gig of compilation product on every build. We used up the endurance on a consumer-level Micron SSD in about a year. No d…
Maybe there's room for a 'file write filter' that avoids writing identical data back to the same file. To save SSD lifetime. Sounds like it would have application.
Or if the exact same intermediate files are being overwritten over and over again, wouldn't a RAMDrive be a good place for them?
Re: An SSD Endurance Experiment: They're All Dead (2015)
#6Earlier quoted context omitted.
Maybe there's room for a 'file write filter' that avoids writing identical data back to the same file. To save SSD lifetime. Sounds like it would have application.
Or if the exact same intermediate files are being overwritten over and over again, wouldn't a RAMDrive be a good place for them?
There's also something to be said for having a build system that can correctly do incremental rebuilds and caching of outputs, which could massively ease the SSD write load.
Re: An SSD Endurance Experiment: They're All Dead (2015)
#7Earlier quoted context omitted.
Or if the exact same intermediate files are being overwritten over and over again, wouldn't a RAMDrive be a good place for them?
There's also something to be said for having a build system that can correctly do incremental rebuilds and caching of outputs, which could massively ease the SSD write load.
You guys are all adorable software devs :-). You're trying to solve a problem with software that just isn't that big a deal: high endurance drives exist, or just buy a new one every year.
Re: An SSD Endurance Experiment: They're All Dead (2015)
#8I loved this series. It inspired us to do similar experiments with SSDs as we were spec'ing out new servers. I highly recommend doing this so you get a feel for what SMART looks like for your specific SSDs. Its nice to be able to monitor that to have some idea when your SSDs are going to die, especially if most of your drives are aging together.
Re: An SSD Endurance Experiment: They're All Dead (2015)
#9Continuous Integration systems can really burn through SSD endurance. If you have a large, compiled code base which rebuilds on every checkin, you will be creating and deleting object code constantly. Use smartmontools or HDD Guardian to keep an eye on endurance. Our code base creates around half a gig of compilation product on every build. We used up the endurance on a consumer-level Micron SSD in about a year. No d…
If it's not too big, could you just use tmpfs for compilation, and copy the final results to persistent storage if needed?
Just food for thought; your point remains valid.
Re: An SSD Endurance Experiment: They're All Dead (2015)
#10Continuous Integration systems can really burn through SSD endurance. If you have a large, compiled code base which rebuilds on every checkin, you will be creating and deleting object code constantly. Use smartmontools or HDD Guardian to keep an eye on endurance. Our code base creates around half a gig of compilation product on every build. We used up the endurance on a consumer-level Micron SSD in about a year. No d…
If it's not too big, could you just use tmpfs for compilation, and copy the final results to persistent storage if needed? Just food for thought; your point remains valid.
DevOps here: This is the solution. Its also stupid fast if everything is done in RAM (just ensure you're not swapping out to disk).