> 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

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