btrfs/ZFS 会让 ECC RAM 过时吗?

btrfs/ZFS 会让 ECC RAM 过时吗?

ECC 内存建议在服务器中使用以尽量减少/防止数据损坏。

btrfs如果您的服务器使用(或ZFS)作为文件系统(据说这两者都可以防止数据损坏),那么 ECC RAM 是否会过时?

答案1

我不确定 btrfs,但 ZFS 和 ECC RAM 就像烤面包和黄油一样……但没有 ECC 的 ZFS 也就像烤面包和黄油一样。

TL;DR- 在 ZFS 中使用 ECC RAM 是件好事(因为使用 ECC RAM 总体上是件好事),但不在 ZFS 中使用 ECC RAM 也不会对你造成任何损害,因为 ZFS 就是这么好。不过,我不会说 ECC RAM 已经过时了,因为除了文件系统存储之外,还有更多的事情要做。任何地方的错误都是坏事。ZFS 只是帮助限制文件系统中的错误。下面是如何/为什么...

请参见http://jrs-s.net/2015/02/03/will-zfs-and-non-ecc-ram-kill-your-data/并仔细阅读。感谢 Jim Salters 提供以下内容。

如果该网站丢失,我将发布相关内容:

第一:ECC RAM

什么是 ECC RAM?这是个好主意吗?

ECC 代表纠错校验和。简而言之,ECC RAM 是一种特殊的服务器级内存,可以检测和修复一些最常见的内存损坏。有关 ECC RAM 如何做到这一点以及它可以纠正和不能纠正哪些类型的错误的更多详细信息,兔子洞就在这里

现在我们知道了什么是 ECC RAM,这是一个好主意吗?当然。内存错误,无论是由于硬件故障还是宇宙辐射的影响(是的,确实如此)都是存在的。它们确实会发生。如果它发生在一个特别重要的位置,您将丢失数据。就是这样。这是无可争辩的。

第二:ZFS

什么是 ZFS?这是一个好主意吗?

ZFS 是一个校验和文件系统。这意味着对于每个提交到存储的块,还会写入该块内容的强哈希值(有点误导性,也称为校验和)。(验证哈希值写入指向块本身的指针,该指针也在指向自身的指针中进行校验和,依此类推。它一直都是乌龟。兔子洞开始了在这里对于这个。

这是个好主意吗?当然。将 ZFS 校验和与冗余或奇偶校验相结合,您现在就拥有了一个自我修复阵列。如果磁盘上的某个块损坏,下次读取时,ZFS 将发现它与其校验和不匹配,并将加载冗余副本(在镜像 vdev 或多副本存储的情况下)或重建奇偶校验副本(在 RAIDZ vdev 的情况下),并假设该块的副本与其校验和匹配,将默默地向您提供正确的副本,并针对未通过的第一个块记录校验和错误。

ZFS 还支持清理,这在下一节中将变得很重要。当您告诉 ZFS 清理存储时,它会读取它知道的每个块(包括冗余副本),并根据它们的校验和进行检查。任何故障块都会自动用好块覆盖,前提是存在好的(通过的)副本,无论是冗余的还是从奇偶校验重建的。定期清理是维护 ZFS 存储池以防止长期损坏的重要组成部分。

情况/关注

ZFS 和非 ECC 是否比非 ZFS 和非 ECC 更糟糕?死亡边缘又如何?

好吧,很容易证明 RAM 中的翻转位意味着数据损坏:如果您将翻转的位写回到磁盘,那么恭喜,您刚刚写入了坏数据。这是毋庸置疑的。这里真正的问题不是 ECC 是否好,而是非 ECC 是否对 ZFS 特别成问题。通常抛出的场景是令人恐惧的 Scrub Of Death。

TL;DR 版本的场景:ZFS 位于具有非 ECC RAM 的系统上,该 RAM 具有卡住位,其用户启动清理,并且由于内存损坏,好块无法通过校验和测试,并被损坏的数据覆盖,从而立即毁掉整个池。据我所知,这个想法源自 FreeNAS 论坛上一位名叫 Cyber​​jock 的非常多产的用户,他在此阐述了这个想法 此处讨论。这是一个可怕的想法——如果本来应该保护系统安全的东西却毁了系统怎么办?疯了!不!

问题是,所写的场景实际上没有意义。首先,即使 RAM 中某个特定地址有卡住位,您也不会让整个文件系统都通过该地址运行。这不是内存管理的工作方式,如果内存管理是这样工作的,您甚至无法启动系统:当它无法加载操作系统时,它就会崩溃并严重烧毁。所以不,您可能会在这里或那里损坏一个块,但您不会通过粉碎机逐个珍贵的块来破坏整个文件系统。

但我们在这里要小心谨慎。假设你只用这种方法损坏了 5,000 个块中的一个。那仍然会很可怕。因此,让我们研究一下更合理的想法,即在清理过程中由于 RAM 损坏而损坏一些数据。假设我们的 RAM 不仅不能 100% 正常工作,而且还非常邪恶,并尽其天真但热情的最大努力在清理过程中专门杀死你的数据:

首先,您读取一个块。这个块是好的。它是写入完好磁盘的完好数据,校验和完全匹配。但是该块被读入恶意 RAM,恶意 RAM 会翻转一些位。这些位可能在数据本身中,也可能在校验和中。无论哪种情况,您完好的块现在似乎与其校验和不匹配,而且由于我们正在清理,ZFS 将尝试实际修复磁盘上的“坏”块。哎呀!现在怎么办?

接下来,您将读取同一块的副本 - 此副本可能是冗余副本,也可能是从奇偶校验重建的,具体取决于您的拓扑结构。冗余副本很容易想象 - 您实际上是在另一个磁盘上存储了该块的另一个副本。现在,如果您的恶意 RAM 保留此块,ZFS 将看到第二个副本与其校验和匹配,因此它将使用与最初相同的数据覆盖第一个块 - 这里没有数据丢失,只是浪费了几个磁盘周期。好的。但是,如果您的恶意 RAM 在第二个副本中翻转了一点怎么办?由于它也不匹配校验和,因此 ZFS 不会覆盖任何内容。它会记录该块的不可恢复的数据错误,并将两个副本保留在磁盘上不变。没有数据被损坏。稍后的清理将尝试读取该块的所有副本并验证它们,就像错误从未发生过一样,如果这次任何一个副本通过,错误将被清除,并且该块将再次被标记为有效(任何未通过验证的副本都将被覆盖)。

嗯,嗯。听起来还不错。那么,邪恶的 RAM 需要做什么才能在清理过程中用损坏的数据覆盖好数据呢?首先,它需要在初始读取它想要损坏的每个块时翻转一些位。然后,在从奇偶校验或冗余中第二次读取块的副本时,它不仅需要翻转位,还需要以某种方式翻转它们,从而产生哈希冲突。换句话说,随机的位翻转不行——你需要在数据中进行一些位翻转(校验和中可以有或没有更多的位翻转),这些位加起来会使损坏的数据正确地哈希到校验和中的值。默认情况下,ZFS 使用 256 位 SHA 验证哈希,这意味着单个位翻转有 1/2^256 的机会给你一个现在与其校验和匹配的损坏块。公平地说,我们在这里使用的是邪恶的 RAM,因此它可能会进行大量实验,它会尝试翻转数据和校验和本身中的位,并且它会对任何单个块执行多次。但是,这是 2^256 分之一(即大约 10^77 分之一)的几率,这仍然使它实际上发生的可能性微乎其微……如果您的 RAM 如此邪恶,无论您是否使用 ZFS,它都会毁掉您的数据。

回复:擦洗

这里有关于数据丢失的合理担忧。注意!

但如果我不擦洗怎么办?

好吧,如果您不进行清理,那么您的邪恶 RAM 将不得不等待您实际写入相关块,然后才能破坏它们。不过幸运的是,您几乎整天都在写入存储……包括组织整个套件和 kaboodle 的元数据。第一次更新文件所在的目录时,BAM!它抓住了!如果您停下来想一想,在这个邪恶的 RAM 场景中,ZFS 非常有用,因为您的 RAM 现在不仅需要邪恶,而且还要足够明亮才能持续发起碰撞攻击。因此,如果您运行的非 ECC RAM 被证明是令人震惊的、Lovecraftianishly 邪恶的,ZFS 将减轻损害,而不是放大损害。

顺便说一句,如果您使用的是 ZFS 并且没有进行清理,那么您将面临长期故障。如果磁盘上有损坏,则只有当您确实拥有损坏块的冗余或奇偶校验副本且该副本完好无损时,清理才能修复它。一旦损坏了给定块的所有副本,再修复它就太晚了——它已经不存在了。不要害怕清理。(好吧,在高需求时期,也许要对清理对性能的影响有点警惕。但不要担心清理会毁掉您的数据。)

再次感谢 Jim Salters 发布此文。

答案2

椭圆曲线是类似紧凑校验和的循环编码,也可以纠正值。

您需要两种 ECC。否则,在写入之前通过内存传输数据时可能会损坏数据,ECC FS 会接受损坏的数据并以此方式保护它。如果它在非 ECC FS HDD 上损坏,则 ECC 内存会在加载时接受损坏的数据。无论如何,好的服务器只允许 ECC 内存。

https://en.wikipedia.org/wiki/Hamming_code#Hamming_codes_with_additional_parity_(SECDED)https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction更多细节。

假设它向字节添加了三个额外的位,并允许检测和例如修复最多两个错误位

正如您现在所看到的,ECC 对 FS 和 RAM 的应用是独立的。

RAID6 还允许您将 ECC 与任何 FS 一起使用。

相关内容