这种统计数据没什么意义。

现代操作系统，本来就有层层机制，消减内存内容受损（因故障或者攻击者恶意）的影
响。

如果内存发生bit flip，那么，它会发生在操作系统整个寻址空间的随机位置，造成后
果五花八门。

比如：

发生在未分配的内存空间——啥事都不会发生，原来就是垃圾数据；

发生在往外发送网络数据缓存区——很可能没啥大事，坏包一个，被对方丢弃要求重发
；

发生在程序运行数据中——也可能啥事没有，被运行中的检查发现，这个exception被捕
捉处理了；

当然也有捕捉处理不到的，某进程segfault，或者kernel panic，甚至整个系统崩溃，
这里对文件系统的影响就是未写入到文件系统的缓冲区数据丢失。但对zfs，btrfs这类
COW文件系统上原有的数据应该不会有问题，因为它们只改写新的数据块，除非你在干文
件系统级别的重IO维护操作，尽管这样，后果可能比你的误挂载轻很多。

而用户最担心的，会永久应用到文件系统的，可能就是内存内容损坏刚好没引起任何浪
花，逃脱检查，静默的写入到磁盘中转为合法正式数据。前面种种可能分下来，这个不
会多的。

讨厌服务中断，数据有一丁点损坏可能的关键性业务，当然是必须上ECC了，但是，ECC
不免费。很多时候，休闲用户容忍一定频率的死机，定期scrub，也能覆盖大部分。

所以我让你注意一下，你不用ecc的时候，系统如何的不稳定。在文件系统倒霉前，系统
一定会不稳到一定程度，自己评估上ECC的必要性。

如果自己上ECC成本很低，不用纠结，上就是了。锦上添花好。


【 在 ttaudi 的大作中提到: 】
: 内存多大？是7x24小时开机吗？
: 我看说32G内存连续开机5天就会出现1bit错误，那篇新闻也说，如果不是连续开机，遇到1bit错误的概率很小。
--
修改:Dazzy FROM 119.130.152.*
FROM 119.130.152.*