Comment by deckard1 | Hacker News Reader

Comment by deckard1 | Hacker News Reader

> a multitude of bit flip errors

ECC can only report >1 bit flip per word. It can't correct it. If your memory is going bad, the chance of multiple bit failure is going to be much higher than the stray bit flip from other causes (mind you, I have 32GB ECC running right now and have seen zero bit flips over 1.5 years).

I'm not arguing against ECC. I have it and run it myself. But this blog post is an argument for ZFS and regular backups. Failures can occur at many other places than RAM. I had a drive that had corruption and I thought went bad. Turns out, bad SATA cable. A week later I upgraded from cable internet to 1Gbit fiber. My speeds were not at all what I expected. Turns out... bad ethernet cable. Lightning can strike twice I guess.

> By the way, you’d better believe that your disk(s) have all kinds of error correction schemes built into them, which work automatically and transparently.

Well...

https://twitter.com/xenadu02/status/1495693475584557056

https://www.tomshardware.com/news/sk-hynix-sabrent-rocket-ss...

https://twitter.com/bsdphk/status/1495899958960136202

> If your memory is going bad, the chance of multiple bit failure is going to be much higher than the stray bit flip from other causes

It's completely possible for a single DRAM cell to go bad permanently.

> But this blog post is an argument for ZFS

ZFS won't save you if what you tell it to put into a file is wrong. And I think that corrupting ZFS' own in-RAM data structures voids your ZFS warranty.

> and regular backups.

Of course you should have regular backups. But do you really feel like spending hours restoring from a backup (and then maybe weeks finding things you didn't restore)? Do you feel like trying to guess how far back you have to go to get to a good backup of a corrupted file? Do you want to lose whatever new work got corrupted between the time your memory failed and the time you finally noticed it?

OP's machine was corrupting data for weeks. You can't just roll all your work back to several weeks ago. Most of us can't, anyway.

You need backups and ECC.

> I had a drive that had corruption and I thought went bad. Turns out, bad SATA cable.

If a bad cable did that, something wasn't doing SATA CRC checking the way it was supposed to (or wasn't reacting to detected CRC errors the way it should have). Similar in spirit to ECC checking for memory.

> My speeds were not at all what I expected. Turns out... bad ethernet cable.

It probably got slow because of retransmissions. If there hadn't been CRCs on both the Ethernet layer and higher layers, it could possibly have just silently corrupted your data.

You need to cover as much of a computer system as you can with error detection and correction, or you always lose. Even one big failure in a lifetime can pay for a lot of ECC RAM.

> If your memory is going bad, the chance of multiple bit failure is going to be much higher

When a chip starts going bad, the thousands of error reports will more than make up for the errors that slip through.

Just make sure reporting is working.

> Well...

Well what?

Those drives were lying about finishing writes, which is barely related to losing data that was written, and especially data that was written more than a few seconds ago. And if drives didn't have ECC, data loss would be a million times more common.

It also allows for runtime detection of bad actors attempting to flip memory.

Reply on news.ycombinator.com