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

31–40 of 54 posts

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

#31

Post by imtringued »

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.

RAM is more expensive than SSDs but it's still very cheap at roughly $5 per GB. Higher density 32GB DIMMs cost only a bit more at $7 per GB. You can buy terabytes of RAM for a few thousand dollars.

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

#32

Post by ptx »

reitanqild wrote: post #26
digikata wrote: post #15

Earlier quoted context omitted.

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

For me? Kind of yes. Only I have subscription overload. Every newspaper and their dog wants to sell me subscriptions but I generally don't read newspapers daily. I'd love to have access to this data through some spotify-for-text service or Blendle or something though. I guess I'm not alone in wanting both to pay researchers, bloggers, journalists etc etc, but based on what I read, not based on a monthly subscribtion…

Maybe Flattr [0] is close enough? You set a monthly budget, pick things to support over the course of the month, and at the end of the month those things automatically get their slice of your pre-set budget.

[0] https://flattr.com/

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

#33

Post by cgag »

toomuchtodo wrote: post #10
peller wrote: post #9

Earlier quoted context omitted.

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

People keep saying this but compiling seems super CPU bound so im confused.

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

#34

Post by nitrogen »

cgag wrote: post #33
toomuchtodo wrote: post #10

Earlier quoted context omitted.

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

People keep saying this but compiling seems super CPU bound so im confused.

Disk seeks when lopking up the next file to compile used to be a huge bottleneck.

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

#35

Post by verytrivial »

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?

Then again, I wonder how much impact write amplification[1] can have on hitting that limit without actually pumping that many bits towards the drive.

[1] https://en.wikipedia.org/wiki/Write_amplification

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

#36

Post by hvidgaard »

nitrogen wrote: post #34
cgag wrote: post #33

Earlier quoted context omitted.

People keep saying this but compiling seems super CPU bound so im confused.

Disk seeks when lopking up the next file to compile used to be a huge bottleneck.

At least for C#, it is entirely CPU bound. Faster CPUs and more cores will increase the IO, but not enough to matter anything.

But the point about SSD endurance still stands, a ramdisk solves that problem.

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

#37

Post by chrisbennet »

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

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.

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

#38

Post by stavros »

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

The article is wrong on this point, and on Intel's intentions, as far as I can tell. Intel has a "Supernova" feature ( http://itpeernetwork.intel.com/data-integrity-in-solid-state... ) which will cause some drive models to brick themselves if certain conditions are met - errors in the control path, for example, which basically mean you cannot trust the drive at all. The supernova feature is only claimed for enterpris…

My data point was that I got an Intel SSD back in 2010 (one of the first affordable ones, $500 for 160 GB) and it started showing bad sectors in 2013. I immediately copied all my data off, and sent it to intel, who sent me a replacement for free. The replacement has been working fine ever since.

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

#39

Post by daemin »

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

The article is wrong on this point, and on Intel's intentions, as far as I can tell. Intel has a "Supernova" feature ( http://itpeernetwork.intel.com/data-integrity-in-solid-state... ) which will cause some drive models to brick themselves if certain conditions are met - errors in the control path, for example, which basically mean you cannot trust the drive at all. The supernova feature is only claimed for enterpris…

They did only have a sample size of 1 for each different drive type, so it's not exactly an exhaustive test.

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

#40

Post by majewsky »

dasmoth wrote: post #29
benley wrote: 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.

The CI absolutists tend to yell "reproducible builds" at this point and argue that things should be built from scratch every time.

Well, yeah. Reproducible builds are valuable. If you don't think so, then have fun trying to rollback to a commit that can only be built by building a specific set of commits leading up to it in the right order.
Post reply on HN