Live data from Hacker News

An SSD Endurance Experiment: They're All Dead (2015)

techreport.com

11–20 of 54 posts

Re: An SSD Endurance Experiment: They're All Dead (2015)

#11
post #7
post #6

Earlier quoted context omitted.

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.

That's cute. Require maintenance where none is actually needed. Everyone hosting a CI now needs a hardware guy, too.

Bandaid solutions (replace every x months, buy something bigger/faster, etc) are not the way to go. The hardware solution to this is not buy a high-endurance drive but to buy more RAM and set up a tmpfs build directory - or buy a ram drive and use that for build instead of you want to eliminate even that software configuration step.

Re: An SSD Endurance Experiment: They're All Dead (2015)

#12
post #9
post #3

Continuous 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.

Wouldn't this possibly be faster too?

Is there ever a reason to commit to disk anything you don't keep after a reboot?

Re: An SSD Endurance Experiment: They're All Dead (2015)

#13
It's a fun article but it would have been outrageously good if say 30 examples of each SSD sourced "randomly" had been tested. OK a bit expensive.

"Over the past 18 months, we've watched modern SSDs easily write far more data than most consumers will ever need."

They tested six SSDs and got "...far more data than most consumers..." - that's the takeaway.

Re: An SSD Endurance Experiment: They're All Dead (2015)

#14
Just wondering how it is compare to HDD: (Here's my calculation base on some assumptions, feel free to correct it if you see any errors.)

2.5PB = 2500TB = 2,500,000 GB

2,500,000 GB / (80MB /s typical HDD Speed ) = 31,250,000 seconds = 8680 Hours = 361 days.

It will take HDD 361 days to write 2.5PB at 80MB/s.

I wonder how many HDD can survive 361 days of 80MB/s non stop?

Re: An SSD Endurance Experiment: They're All Dead (2015)

#15
post #13

It's a fun article but it would have been outrageously good if say 30 examples of each SSD sourced "randomly" had been tested. OK a bit expensive. "Over the past 18 months, we've watched modern SSDs easily write far more data than most consumers will ever need." They tested six SSDs and got "...far more data than most consumers..." - that's the takeaway.

Would you be willing to pay for a subscription to a quarterly report for that info?

Re: An SSD Endurance Experiment: They're All Dead (2015)

#17
post #7

Earlier quoted context omitted.

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.

That's cute. Require maintenance where none is actually needed. Everyone hosting a CI now needs a hardware guy, too. Bandaid solutions (replace every x months, buy something bigger/faster, etc) are not the way to go. The hardware solution to this is not buy a high-endurance drive but to buy more RAM and set up a tmpfs build directory - or buy a ram drive and use that for build instead of you want to eliminate even th…

Replacing the SSDs every year might be a valid solution, too.

It may be far cheaper to do so than to spend developer time coming up with a ramdisk solution. And RAM is far more expensive, per GB, than SSDs.

Next year's drives will be cheaper and better, anyway.

Re: An SSD Endurance Experiment: They're All Dead (2015)

#18
post #3

Continuous 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…

ccache

Re: An SSD Endurance Experiment: They're All Dead (2015)

#19
> "Intel doesn't have confidence in the drive at that point, so the 335 Series is designed to shift into read-only mode and then to brick itself when the power is cycled."

I don't understand why Intel wouldn't just configure these drives to go into read-only mode permanently. If I realized my hard drive had become read-only and didn't suspect hard drive failure, my first inclination would be to reboot my computer, not immediately back up all data.

Re: An SSD Endurance Experiment: They're All Dead (2015)

#20

Just wondering how it is compare to HDD: (Here's my calculation base on some assumptions, feel free to correct it if you see any errors.) 2.5PB = 2500TB = 2,500,000 GB 2,500,000 GB / (80MB /s typical HDD Speed ) = 31,250,000 seconds = 8680 Hours = 361 days. It will take HDD 361 days to write 2.5PB at 80MB/s. I wonder how many HDD can survive 361 days of 80MB/s non stop?

> I wonder how many HDD can survive 361 days of 80MB/s non stop?

I wonder how many consumer HDDs can survive that load. I would be shocked if datacenter-grade drives fail after only 361 days of continuous load.

Post reply on HN