系统与基础设施danluu.com
我应该买 ECC 内存吗？（2015）
Should I buy ECC memory? (2015)
2015 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Dan Luu 的这篇文章论证了为什么应该购买 ECC（纠错）内存：内存位翻转错误真实存在且会静默损坏数据，而 ECC 的成本如今已非常低。文章回应了“普通人不需要 ECC”的常见反驳，并引用了 Google 早期因不用 ECC 而付出系统设计代价的教训。
为什么经久不衰：内存错误是长期被低估的工程问题，这篇文章用扎实的论据把“要不要 ECC”一次讲清，多年后仍是装机和选型时的经典参考。
HN 评论精选
Google 早期不用 ECC 的教训：数据完整性应尽量在底层解决
我在 Google 时，有人问一位非常早期的 Googler（我记得是 Craig Silverstein，也可能是 Jeff Dean）职业生涯最大的错误是什么，答案是“早期服务器没用 ECC 内存”。翻看那个时代的源代码和事故复盘，会发现各种丑陋的 hack 和系统设计约束，都源于无法信任 RAM 返回的比特。省下了一点硬件钱，但对系统设计的连锁影响造成的工程师时间损失远超于此。数据完整性这类约束应尽量压到技术栈底层，因为越往上，数据损坏的可能原因会指数级增多。
nostrademons查看英文原文
While I was at Google, someone asked one of the very early Googlers (I think it was Craig Silverstein, but it may've been Jeff Dean) what was the biggest mistake in their Google career, and they said "Not using ECC memory on early servers." If you look through the source code & postmortems from that era of Google, there are all sorts of nasty hacks and system design constraints that arose from the fact that you couldn't trust the bits that your RAM gave back to you. It saved a few bucks in a time period where Google's hardware costs were rising rapidly, but the ripple-on effects on system design cost much more than that in lost engineer time. Data integrity is one engineering constraint that should be pushed as low down in the stack as is reasonably possible, because as you get higher up the stack, the potential causes of corrupted data multiple exponentially.
ECC 能让你知道错误发生过，否则只能事后猜测数据为何损坏
是的，每个读到这里的人都应该用 ECC 内存，非 ECC 内存应该改名叫“错误传播内存”。随机位翻转并不罕见，而且经常发生。大多数支持 ECC 的机器都能报告错误，我大约每年都能看到一两次，比如上个月就有两次可纠正的内存错误。宇宙射线？谁知道呢。你永远不会知道原因，但如果不用 ECC，你根本不会知道错误发生过——只会多年后面对一个再也解不开的加密文件，而所有备份都是同样的损坏。
veidr查看英文原文
Yes. Everybody reading this should use ECC RAM, and non-ECC RAM should be called "error-propagating RAM". Random bit flips aren't cool, and they happen regularly. Most computers that have ECC RAM can report whether errors happen. I see them at least once a year or so. For instance, here are 2 ECC-correctable memory errors that occurred just last month. Cosmic rays? Fukushima phantom? Who knows. You'll never know why they happen (unless it's like a bad RAM module and they happen a lot), but if you don't rock ECC you will never know they happened at all. You'll be left guessing when, years later, some encrypted file can no longer decrypt, and all the backups show the same corruption... [1]: https://www.dropbox.com/s/zndvy3nkv1jipri/2017-03-20%20FUCK%20memory%20errors.png?dl=0 [2]: https://www.dropbox.com/s/6yeoedc7ajzq4u9/2017-03-20%20FUCK%20memory%20errors%20detail.png?dl=0
“ZFS 必须 ECC”是误解，ZFS 作者本人已澄清
请大家别再说 ZFS 需要 ECC 内存了。任何文件系统——FAT、NTFS、EXT4——用 ECC 都更安全。ZFS 实际上是少数几个即使不用 ECC 也仍然更安全的文件系统之一。来源是 ZFS 开发者 Matthew Ahrens 本人的说法。
olavgg查看英文原文
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=26303271#p26303271
原作者澄清立场：ECC 的收益在大规模部署时才统计显著
我想澄清：在原文中我并非反对 ECC，只是陷入了一种巨大的认知失调——一边是“没有 ECC 你的电脑会不断静默损坏数据并崩溃”，另一边是“统计上世界上大多数电脑都不用 ECC”。这两者怎么可能同时成立？支持 ECC 的论点是有说服力的（我认为 Rowhammer 是最好的例子），但它似乎取决于你是否拥有成百上千台协同工作的机器——ECC 的正面效果似乎只在非常大的规模下才在统计上显著。
codinghorror查看英文原文
I just want to be clear that in the original referenced article, I am not anti-ECC per se, I just found myself caught in the massive cognitive dissonance between "you must have ECC in all your computers otherwise they will constantly and silently corrupt your data + crash" and "statistically speaking, most computers in the world do not use ECC". How can both of these things be true? The argument for ECC is credible (I personally think rowhammer is the best example of this actually mattering, but ironically a) you can rowhammer ECC memory just fine and b) DDR4 has hardware features to mitigate rowhammer -- which shows how quickly things are changing), but it also seems to hinge on whether you have hundreds to thousands of computers all working together, e.g. the positive effects of ECC only seem to matter enough statistically at a _very_ large scale.
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选