Hacker News Reader

Comment by mrb | Hacker News Reader

This is not the reason why people recommend ECC. ZFS is so good at detecting corruption (CKSUM errors) that when it happens it is hard to tell what caused it: faulty RAM corrupting data before being written to disk or after being read from disk, or data corrupted on disk? ECC simply helps reduce a good chunk of corruption errors caused by faulty RAM. That said, in my experience there are a few tell-tale signs that RAM is the issue: when you see CKSUM errors poping up infrequently, and not being attributed to consistently the same drive(s).

View on HN

I haven't had any issues so far using four drives mirrored on ZFS, but the ECC issue certainly worries me.

I'd love to run ECC RAM, but I'd have to buy a much more expensive processor, a much more expensive mainboard, and all of my RAM would have to be swapped for moderately more expensive replacements. And DDR3+ is not cheap.

I'm curious though, if ECC consists of a ninth parity bit, is there any reason why a memory controller can't be designed that would, worst case, use every other (identical) stick just to get parity bit(s), as a BIOS configurable option? Sure it'd halve your RAM, or you'd pay a lot more in RAM costs, but not having to buy Xeon processors and mainboards, and getting to reuse your existing RAM, would be worth buying an extra stick of RAM in my opinion.

It seems as processes keep getting smaller, and RAM sizes keep getting larger, that the effects of cosmic radiation are just going to keep getting worse. If we can't get desktop CPUs and mainboards to just switch to ECC, surely this would at least be a better-than-nothing option.

Most modern CPUs have the memory controller integrated on-die, so you'd need a different class of CPU -- and then you're right back to buying a Xeon.

Not necessarily. Some Atoms (e.g. Centerton) are now shipping with ECC support; similarly AMD Kabini processors support ECC.

The "ECC issue" is relevant for all software and by extension, all filesystems. ZFS eliminates so many problems in the storage stack that things it cannot eliminate (like bit-flips from not having ECC) become more noticeable by virtue of fewer things going wrong. Here is some documentation on this:

http://open-zfs.org/wiki/Hardware#ECC_Memory

As for ECC in desktops, I am using whatever interactions that I have with vendors to push for it. Here is a public one:

https://dellideas.secure.force.com/idea2ReadIdea?v=140380318...

> I'd love to run ECC RAM, but I'd have to buy a much more expensive processor, a much more expensive mainboard, and all of my RAM would have to be swapped for moderately more expensive replacements. And DDR3+ is not cheap.

It's cheaper than losing your data.

We spend 20% more on drives than we have disk space and we do it because we love our data. In most use cases, it's wise to trade some performance (in the form of a slower, single socket, less memory) setup for reliability. Unless you need all the performance you can possibly get, a slightly slower but more reliable machine is sound investment.

> if ECC consists of a ninth parity bit

A single bit will allow you to detect an error in a given unit, but not correct it. For correcting a single-bit error, you'd need to pinpoint which bit got flipped and that would require a second parity bit.

I went ECC a couple months ago and managed to find some parts that didn't break the bank, mostly because I held back and stayed a generation behind: GA-6UASL3, E3-1230V2. There are other sacrifices: the motherboard is rather no-frills, and the memory bandwidth isn't that great.

Besides price, another issue against server hardware is that it's generally designed for a server case and therefore doesn't play well with enthusiast cases. The board I got is a little odd in that it uses a layout more typical of consumer boards, though the socket placement is still not ideal.

One of the reasons I went with AMD processors and mobo chipsets for my non-laptop system (and recommend them for anyone who's not concerned about performance per watt) is because AMD doesn't segment the market by processor features.

You choose based on power budget, thermal budget, and presence of on-die graphics. Regardless of how you choose, all processors in a given generation (back to at least the Phenom series and associated mobo chipsets) have ECC support, virtualization support, and whatever other fancy features were slapped in in that generation.

Most MB vendors (other than ASUS) disable ECC for non-server cpu's... Also, it's Unbuffered ECC, not Registered ECC for those looking, and unsure.

> is there any reason why a memory controller can't be designed that would, worst case, use every other (identical) stick just to get parity bit(s), as a BIOS configurable option?

If Intel were interested in allowing you to make use of any parity bits without buying a Xeon, they wouldn't be restricting ECC to Xeons in the first place.

ECC might not cost as much as you think. Here is a barebones ECC setup with 4GB of ram for $230.

http://secure.newegg.com/WishList/PublicWishDetail.aspx?Wish...

FYI, that mb seems to support unbuffered ecc, not the registered ecc stuff you put in the list... AMD + ASUS MB is probably a better option for under $600-800 price points.

FYI: Mid-higher end AMD on Asus motherboards support unbuffered ecc ram. The ram is 2x as much and you won't go above 8/4 cores at modest speed, but it's a good option for homebrew solutions.

Reply on news.ycombinator.com