Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

techreport.com

Post reply on HN
Print view View original

41–50 of 54 posts

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

#41

Post by taspeotis »

tonyplee wrote: post #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?

80 MB/s would imply sequential IO. Much harder test if it were random IO - the drive head would move all over the place all day long.

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

#42

Post by userbinator »

RandomBK wrote: post #20
tonyplee wrote: post #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?

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

80MB/s sequential reads or writes is probably something consumer HDDs can survive for several years. The platters are always spinning, the only difference is that now the drive is continuously reading or writing what's under the head. It's the random accesses (and associated seeks) which stresses them.

There are various comparisons out there which conclude "datacenter-grade" is largely a marketing/warranty thing; the drives themselves may be nearly identical in design.

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

#43

Post by userbinator »

cjensen wrote: 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…

Our code base creates around half a gig of compilation product on every build

500MB? That's tiny in comparison to available RAM today, so I would just say use a RAMdrive and periodically write to the SSD.

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

#44

Post by userbinator »

If you divide the data written at the point where reallocated sectors start appearing by the size, you can figure out the actual average endurance of the flash. That results in:

    400 Samsung 840 Series
    2344 Samsung 840 Pro
    2400 Kingston HyperX 3K
    2800 Intel 335 Series
    4400 Corsair Neutron GTX

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

#45

Post by RealityVoid »

martey wrote: post #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,…

I remember having a contradictory discussion at work about the design of a emulated eeprom driver for some embedded product. We had the flash memory hardware rated for a number of erase/write cycles. The question was what should we do when the cycle number is greater than that rated number. I said we should continue functioning and eventually raise a warning or something. But my colleagues were saying we should simply kill the hardware and brick ourselves. I was adamantly against this but they were citing safety concerns that maybe the flash could get corrupted and we weren't supposed to support that long of a lifetime anyway. We had a lot of safety mechanisms and redundancies baked in so data corruption would not happen. And my argument was mainly that, yes, if unrecoverable data corruption happens, brick it, but until the hardware forces you to close shop, the SW should continue running as long as possible. I don't know what they ended up implementing because I soon left, but I think they went with the self-bricking option.

Anyways, I just wanted to share this nice anecdote and I can't help but think that maybe somewhere, some Intel engineers had some discussion very similar to my own.

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

#46

Post by smcl »

chrisbennet wrote: post #37
mjevans wrote: post #24

Earlier quoted context omitted.

Thanks for reminding me of the EXACT reason that Intel drives were on my personal blacklist of manufacturers to NEVER buy SSDs from.

When I read that I also thought "That's horrible, guess I won't buy that drive." When I read further though, I discovered that all the drives in his test become unreadable ("bricked"?) when they eventually failed.

Well for the others, if you really care about it you can see that sectors start getting remapped and think "ah ok time to start thinking about backing this data up and replace the drive" whereas if I understand correctly on the Intel one you pretty much immediately need to backup the data and hope that you don't need to restart or lose power before you've backed up what you need.

I'm sure it's more nuanced than that but my reaction was definitely "steer clear of the Intel drives ..." when I read this so perhaps someone can clarify.

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

#47

Post by konstmonst »

Reason077 wrote: post #17
ComputerGuru wrote: post #11

Earlier quoted context omitted.

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.

There is no "solution" to speak of, tmpfs can be mounted on any directory on linux, so there is no difference to normal build process at least on linux. Also for example I can serialise build jobs in jenkins, so the total amount of space required will be spread over time.

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

#48

Post by colanderman »

benley wrote: post #6
Shendare wrote: post #5

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

Incremental builds are antithetical to continuous integration, for the reason that even a minor dependency issue results in a non-reproducible build.

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

#49

Post by squarefoot »

smcl wrote: post #46
chrisbennet wrote: post #37

Earlier quoted context omitted.

When I read that I also thought "That's horrible, guess I won't buy that drive." When I read further though, I discovered that all the drives in his test become unreadable ("bricked"?) when they eventually failed.

Well for the others, if you really care about it you can see that sectors start getting remapped and think "ah ok time to start thinking about backing this data up and replace the drive" whereas if I understand correctly on the Intel one you pretty much immediately need to backup the data and hope that you don't need to restart or lose power before you've backed up what you need. I'm sure it's more nuanced than that…

Backup shouldn't be something to do when the drive is exhaling its last breath or even showing first symptoms, it should be done often and in a transparent way. On a laptop the best practice is to arrange a sync with a server (NAS etc.) when one gets home. If done incrementally it requires from seconds to minutes and is fully automatic. Unfortunately making backups still isn't common practice; most users see a NAS or even an external drive as wasted money. They feel safe by "backing up" some data on a USB key only to discover how volatile and unsafe it might be when it's too late (breaks, washing machine, theft, loss, etc.)

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

#50

Post by pbhjpbhj »

userbinator wrote: post #43
cjensen wrote: 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…

Our code base creates around half a gig of compilation product on every build 500MB? That's tiny in comparison to available RAM today, so I would just say use a RAMdrive and periodically write to the SSD.

Indeed, my Ubuntu recently created multiple 22G log files several days in a row (some USB issue or other fixed by updating kernel). Wouldn't have been an issue but the disk was nearly full.
Post reply on HN