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

Should I buy ECC memory? (2015)

danluu.com

Post reply on HN
Print view View original

231–237 of 237 posts

Re: Should I buy ECC memory? (2015)

#231

Post by tjoff »

cyberpunk wrote: post #224
tjoff wrote: post #222

Earlier quoted context omitted.

No. ZFS is in much greater need for ECC than most other filesystems. 1. ZFS doesn't come with any disk repair tools and the ones that exist are not nearly as capable as for other filesystems (the ZFS motto is that it is too costly to repair filesystems, just recover from tape instead (here we can sense the intended audience of ZFS)). If the wrong bit get's flipped your entire pool might be gone (you can of course spe…

Well; I don't think 'lack of repair tools' for ZFS is the reason that ECC is the suggested good practice; but I can sort of agree that recovering from a badly farked pool isn't fun having been down that rabbithole... Regardless of ZFS, this is why we architect our storage to cope with such potential borkage (which has, incidentially, only happened to me _ONCE_ in ~8 years of zfs in prod, had nothing to do with silent…

The whole point of the ZFS needs ECC statement is that it holds true even for non-significant deployments. Such as a home-NAS. And at that scale it comes with a quite significant cost increase. Rather than reusing your old workstation you need a new server class machine with lots of RAM, even though the CPU requirements aren't that high.

If your backend is a zvol you get the integrity advantages and cheap snapshots regardless of your VM filesystem, so it isn't really a fair comparison with an "EXT all the way" scenario.

Re: Should I buy ECC memory? (2015)

#232

Post by GuB-42 »

koffiezet wrote: post #198
olavgg wrote: post #26

Can people here please stop posting that ZFS needs ECC memory. Every filesystem, with any name like FAT, NTFS, EXT4 runs more safe with ECC memory. ZFS is actually one of the few that can still be safer if you don't run with ECC memory. Source: Matthew Ahrens himself: https://arstechnica.com/civis/viewtopic.php?f=2&t=1235679&p=...

ZFS is not the cheap option, it was never intended to be - so why bother skimping on ECC? If you're worried about ECC prices - ZFS is probably not for you. It's not that you need ECC for ZFS, but when you're at a point where you're willing to throw money at a storage system where ZFS makes sense, the extra cost of ECC is minuscule. The most expensive hardware requirement of ZFS is that you need disks of the same size…

You can have disks of differing sizes with ZFS, though you are making things difficult for yourself so your point still stands.

However the cost of ECC is not negligible because you need your CPU and motherboard to support it.

The total budget for my NAS was 1000 EUR in 2013, 500 for the 5 3TB disks, 350 for the motherboard+CPU+8GB ECC RAM, and 150 for the case, PSU, system SSD, and accessories. In reality I salvaged 2 3TB disks, lowering the cost to 800. By using non-ECC I could have used a cheaper motherboard and CPU, in addition to cheaper RAM. In fact I would probably have used hardware from an older desktop PC. It would have been a 15-20% saving, or 45% if I take reuse into account. Not negligible.

My previous NAS, running linux soft-RAID, entirely made of salvaged parts except for some of the disks had a few corruption problems. One of them caused by a defective disk. ZFS would have caught it, so even on cheap systems, ZFS has its use.

I also had defective DRAM, rebuilds not going smoothly, etc... That system caused me too many scares, so I decided that the next system would be cheap but not too cheap as to endanger my sanity. I also got a proper backup solution.

Re: Should I buy ECC memory? (2015)

#233

Post by m-j-fox »

jandrese wrote: post #209
m-j-fox wrote: post #125

Earlier quoted context omitted.

Should be about 1/8th more since it's just a 72-bit bus for carrying 64-bits data and 8-bits check. Or rather, your dimm will have 9 chips instead of 8. How they get you is Intel will sell you a xeon which is the exact same die as an i5 in a different package for more money.

It should be 1/8th more, plus a bit for the scrubber. But in practice ECC memory is "enterprise priced" so it's more like double.

Should we do a Kickstarter to manufacture our own DIMMs? Its an easy design and I hate donating to some corporate gross margins. Maybe enough people feel the same.

Re: Should I buy ECC memory? (2015)

#234

Post by dom0 »

__jal wrote: post #111
dom0 wrote: post #50

Earlier quoted context omitted.

> should return the same data that software thought it was writing Hint: In an OS using a page cache (= every OS ) I/O errors are not reliably propagated to applications unless they explicitly sync their dirty pages.

I'm aware of that, but I'm not sure what I'm supposed to take away from it in this context.

That it's difficult to accurately define "what the application thought it wrote" when considering corruption at various abstraction layers; somewhat similar to calculating checksums over already corrupted data.

Re: Should I buy ECC memory? (2015)

#235

Post by blackflame7000 »

fulafel wrote: post #229
blackflame7000 wrote: post #220

Earlier quoted context omitted.

If you write code that detects stack smashing and illegal dereferences then you can terminate the webservice and either have a watchdog restart it or if it crashes multiple times have it taken out of service by the load balancer. There are plenty of ways to handle hardware errors without throwing out the hardware and getting "better" hardware. Technically, You could have a faulty component somewhere between the Ram a…

Even with your proposed checks there remains a high probability to just get silent application data corruption, not crashes. Regarding faulty components, that is one part of ECC's job, but the other part is correcting the regular bit flips that happen with nominally operating DRAM. Flagging faulty components is more useful than you propose. There are not that many places where this corruption can occur, so being able…

ECC ram is not a raid. If corrosion on a trace causes a bit flip from an adjacent line then the ram will recieve rhe corrupt data as valid. There is no parity ram stick to recover from. I never said ECC ram doesnt have a purpose. Im saying you are wasting your money if you think it's essential to running a web sever. Lets be real here, like 80% of computers on the internet stream porn. They dont need ecc ram

Re: Should I buy ECC memory? (2015)

#236

Post by [deleted] »

fulafel wrote: post #229
blackflame7000 wrote: post #220

Earlier quoted context omitted.

If you write code that detects stack smashing and illegal dereferences then you can terminate the webservice and either have a watchdog restart it or if it crashes multiple times have it taken out of service by the load balancer. There are plenty of ways to handle hardware errors without throwing out the hardware and getting "better" hardware. Technically, You could have a faulty component somewhere between the Ram a…

Even with your proposed checks there remains a high probability to just get silent application data corruption, not crashes. Regarding faulty components, that is one part of ECC's job, but the other part is correcting the regular bit flips that happen with nominally operating DRAM. Flagging faulty components is more useful than you propose. There are not that many places where this corruption can occur, so being able…

[deleted]

Re: Should I buy ECC memory? (2015)

#237

Post by lomnakkus »

marcosdumay wrote: post #140
Retra wrote: post #130

Earlier quoted context omitted.

You can't really, but you are now requiring the error to occur specifically in the memory containing your checksum, rather than anywhere in your data.

It deeper than that. What are you calculating the checksum of? Is it corrupted already? If you can't trust your RAM, you have no hard truth to rely on. It's only probabilistic programing or living with the errors. (Although, rereading the GP, he seems to be talking about corrupted binaries. Yes, you can catch corrupted binaries, but only after they corrupted some data.)

It's even worse than that: where's the code that's doing all the chucksumming and checking of checksums? Presumably it came from memory at some point...

Maybe it was read fine from the binary the first time, but the second time...

At some point you just have to hope.

Post reply on HN