静默磁盘错误和Linux交换的可靠性

我的理解是，硬盘驱动器和SSD会在驱动器内部实现一些基本的错误纠正，而大多数RAID配置（例如mdadm）将依赖于此来决定何时驱动器无法纠正错误并需要脱机。但是，这取决于存储的错误诊断准确率100％。事实并非如此，并且像两个驱动器的RAID-1镜像这样的常见配置将很容易受到攻击：假设一个驱动器上的某些位被静默损坏，并且该驱动器未报告读取错误。因此，诸如btrfs和ZFS之类的文件系统将实现其自己的校验和，以便不信任有故障的驱动器固件，故障SATA电缆等。

同样，RAM也可能存在可靠性问题，因此我们拥有ECC RAM来解决此问题。

我的问题是：如何保护Linux交换文件免受两磁盘配置（即，使用主线内核驱动程序）上的驱动器固件捕获的静默破坏/位腐的静默破坏/位腐烂？在我看来，此处缺少端到端保护的配置（例如btrfs提供的配置）在某种程度上抵消了ECC RAM带来的省心。但是我想不出一个好方法：

• btrfs根本不支持交换文件。您可以从btrfs文件设置一个循环设备，然后在该设备上进行交换。但这有问题：
  • 随机写入效果不佳：https：//btrfs.wiki.kernel.org/index.php/Gotchas#Fragmentation
  • 关于禁用写时复制的建议也将禁用校验和-从而破坏了本练习的重点。他们的假设是数据文件具有自己的内部保护。
• ZFS Linux上允许使用ZVOL作为交换，我想可以工作：http://zfsonlinux.org/faq.html#CanIUseaZVOLforSwap -然而，从我读书，ZFS通常苛刻的内存，并得到它的交换工作-仅应用程序听起来像一些工作来解决它。我认为这不是我的首选。为什么要为了可靠的交换而不得不使用树外内核模块，这超出了我的范围-在当今时代，对于大多数现代Linux发行版/内核，肯定有一种方法可以做到这一点？
• 有其实用的补丁，使内存管理器本身的校验，对于正是我在这个问题上讨论的原因，一个Linux内核邮件列表上的螺纹： http://thread.gmane.org/gmane.linux.kernel/989246 -不幸的是，据我所知，该补丁死了，并且从未出于我不知道的原因将其发布到上游。太糟糕了，听起来像是一个不错的功能。另一方面，如果将交换放在RAID-1上-如果损坏超出了校验和的修复能力，则希望内存管理器在出现紧急情况或其他原因之前尝试从其他驱动器读取数据。可能超出了内存管理器应做的工作范围。

综上所述：

• RAM具有ECC纠正错误
• 永久存储中的文件具有btrfs来更正错误
• 掉期有??? <---这是我的问题

我们信任从交换中检索到的数据的完整性，因为存储硬件具有校验和，CRC等。

在上面的评论之一中，您说：

是的，但是它不能防止磁盘自身外部的位翻转

“它”表示此处的磁盘校验和。

的确如此，但是SATA使用32位CRC来存储命令和数据。因此，您有40亿分之一的机会损坏磁盘和SATA控制器之间的数据。这意味着连续的错误源可能每传输125 MiB就会引入一次错误，但是罕见的，随机的错误源（如宇宙射线）将以极小的速率导致无法检测到的错误。

还要意识到，如果您的某个源导致未检测到的错误的速率接近每125 MiB传输一个，则性能会很糟糕，因为需要重新传输的检测到的错误数量很高。监视和日志记录可能会及时提醒您该问题，以避免未发现的损坏。

至于存储介质的校验和，每个SATA（及其之前的PATA）磁盘都使用某种类型的每扇区校验和。“企业”硬盘的特征之一是较大的扇区，这些扇区受附加的数据完整性功能保护，从而大大减少了无法检测到的错误的可能性。

没有这些措施，每个硬盘驱动器中的备用扇区池将毫无意义：驱动器本身无法检测到坏扇区，因此永远无法交换新扇区。

在另一条评论中，您要求：

如果SATA值得信赖，为什么会有校验和的文件系统，如ZFS，btrfs，ReFS？

一般而言，我们不要求交换来长期存储数据。交换存储的限制是系统的正常运行时间，并且交换中的大多数数据不会持续那么长时间，因为通过系统虚拟内存系统传输的大多数数据属于寿命较短的进程。

最重要的是，随着内核和libc更新，虚拟化，云架构等频率的增加，正常运行时间通常已经缩短了很多年。

此外，交换中的大多数数据在一个管理良好的系统中固有地被废弃，因为它本身不会耗尽主RAM。在这样的系统中，最终交换的唯一内容是程序不经常使用的页面（如果有的话）。这比您可能猜到的更为普遍。您的程序链接到的大多数动态库中都有您的程序不使用的例程，但是必须由动态链接程序将它们加载到RAM中。当操作系统发现您没有使用库中的所有程序文本时，它会将其交换出去，从而为程序正在使用的代码和数据腾出空间。如果这些换出的内存页损坏了，谁能知道？

与此相反，我们希望ZFS能够持久且持久地存储数据，因此ZFS不仅会持续超出系统当前的正常运行时间，而且还会超出构成存储系统的各个存储设备的使用寿命。ZFS等正在解决的时间尺度问题比交换解决的问题长大约两个数量级。因此，与Linux交换相比，我们对ZFS的损坏检测要求更高。

ZFS等等与交换在这里的另一个关键方式不同：我们不将RAID系统一起交换。当在一台计算机上使用多个交换设备时，这是一种JBOD方案，与RAID-0或更高版本不同。（例如，macOS的链式交换文件方案，Linux的swapon等等），因为交换设备是独立的，而不是像RAID那样相互依赖，所以我们不需要大量的校验和，因为更换交换设备并不涉及寻找其他相互依赖的交换设备。应该在替换设备上保存的数据。用ZFS术语来说，我们不会从其他存储设备上的冗余副本中重新分配交换设备。

所有这些确实意味着您必须使用可靠的交换设备。我曾经用一个20美元的外部USB HDD机箱救出一个故障的ZFS池，却发现该机箱本身并不可靠，从而在过程中引入了自身的错误。ZFS强大的校验和保存了我的知识。使用交换文件对存储介质进行如此轻率的处理是无法避免的。如果交换设备快要死了，并且正在接近最坏的情况，即每传输125 MiB就会注入不可检测的错误，则只需尽快更换它。

这个问题的整体偏执感演变为拜占庭将军问题的一个例子。继续阅读，在关于向计算机科学界描述该问题的学术论文中考虑1982年的日期，然后确定您在2019年是否有新的想法来解决此问题。如果不是这样，那么也许您将只使用由三十年都知道拜占庭将军问题的CS毕业生设计的技术。

这是久经考验的基础。您可能无法提出尚未在计算机科学期刊中进行过讨论的想法，异议或解决方案。

SATA当然不是绝对可靠的，但是除非您打算加入学术界或其中一个内核开发团队，否则您将无法在这里为当前的技术水平做出实质性的补充。正如您已经指出的，这些问题已经可以解决：ZFS，btrfs，ReFS ...作为OS用户，您只需要相信OS的创建者会为您解决这些问题，因为他们也知道关于拜占庭将军。

它是目前还没有实际的把你的交换文件的ZFS或增加了Btrfs的顶部，但如果上面不放心你，你至少可以把它顶上XFS和EXT4。这将比使用专用交换分区更好。

dm完整性

请参阅：说明文件/device-mapper/dm-integrity.txt

dm-integrity通常在日记模式下使用。在交换的情况下，您可以安排不进行日志记录。这可以大大降低性能开销。我不确定您是否需要在每次引导时重新格式化完整性分区，以避免在异常关闭后捕获错误。

在的最初公告中dm-integrity，作者声明了对“更高级别的数据完整性保护”的偏好。在交换的情况下，这将打开将校验和存储在RAM中的可能性。但是，该选项既需要对当前交换代码进行不重要的修改，又会增加内存使用率。（当前代码使用范围（而非单个页面/扇区）有效地跟踪交换）。

DIF / DIX？

Oracle在Linux 2.6.27（2008）中添加了DIX支持。

使用DIX是否提供端到端的完整性？

您可以咨询您的供应商。我不知道你怎么知道他们是否在说谎。

需要DIX来保护OS（操作系统）和HBA之间正在传输的数据。

DIF本身可以增强对HBA和存储设备之间传输的数据的保护。（另请参见：有关错误率差异的一些数字的介绍）。

正是由于保护字段中的校验和是标准化的，因此在技术上可以实现DIX命令而不为静态数据提供任何保护。只需让HBA（或存储设备）在读取时重新生成校验和即可。最初的DIX项目已非常清楚地表明了这一观点。

• DIF / DIX 与逻辑块校验和 正交
  • 我们仍然爱你，btrfs！
  • 逻辑块校验和错误用于检测损坏的数据
  • 检测发生在读取时间
  • ...可能几个月后，原始缓冲区丢失
  • 如果原始缓冲区出现乱码，则任何冗余副本也可能是错误的
• DIF / DIX关于积极预防腐败
  • 首先防止将不良数据存储在磁盘上
  • ...并在从内存中删除原始缓冲区之前找出问题

- 来自oss.oracle.com的lpc08-data-integrity.pdf

他们关于DIX的早期文章之一提到即使驱动器不支持DIF，也可以在OS和HBA之间使用DIX。

在当前使用DIX的“企业”环境中，完全不可能有完全的行为。人们会注意到它。同样，DIF基于现有的硬件，可以使用520字节的扇区进行格式化。据称，使用DIF的协议要求您首先重新格式化驱动器，例如参见sg_format命令。

更可能的是不遵循真正的端到端原则的实现。举一个例子，提到了一个供应商，该供应商为DIX提供了较弱的校验和选项以节省CPU周期，然后由堆栈中更下方的较强的校验和代替。这很有用，但不是完整的端到端保护。

或者，操作系统可以生成自己的校验和并将其存储在应用程序标记空间中。但是，当前的Linux（v4.20）不支持此功能。该评论写于2014年，暗示这可能是因为“很少有存储设备实际允许使用应用程序标签空间”。（我不确定这是指存储设备本身，HBA还是两者同时使用）。

可以使用哪些与Linux兼容的DIX设备？

数据和完整性元数据缓冲区的分离以及校验和的选择称为数据完整性扩展[DIX]。由于这些扩展超出了协议主体（T10，T13）的范围，因此Oracle及其合作伙伴正在尝试在存储网络行业协会内部对它们进行标准化。

- v4.20 /文档/块/数据integrity.txt

维基百科告诉我DIF在NVMe 1.2.1中已标准化。对于SCSI HBA，如果我们没有指向的标准，则很难确定这一点。目前，谈论“ Linux DIX”支持可能是最精确的：-)。有可用的设备：

只要硬件供应商对SCSI T10 DIF / DIX [sic]进行了认证，并已对它进行了认证，并且对特定的HBA和存储阵列配置提供了全面的支持，SCSI T10 DIF / DIX [sic]就可以得到完全支持。DIF / DIX在其他配置上不受支持，在启动设备上不支持使用DIF / DIX，在虚拟客户机上也不支持。

目前，已知以下供应商提供此支持...

- RHEL 7.5发行说明，第16章存储

RHEL 7.5发行说明中提到的所有硬件都是光纤通道。

我不知道这个市场。听起来DIX将来可能会在服务器中变得越来越广泛。我不知道为什么它可以用于消费级SATA磁盘-据我所知，甚至没有实际的命令格式标准。我很想知道它是否可以在NVMe上更广泛地使用。

掉期有??? <---这是我的问题

交换在Linux中仍然不受保护（但请参见UPD）。

好吧，当然有Linux上的ZFS可以作为交换存储，但是在某些情况下仍然存在锁定，因此有效地取消了该选择。

Btrfs仍然无法处理交换文件。他们提到了可能使用环回的功能，尽管它的性能很差。有迹象表明，Linux 5最终能否拥有它？

用校验和保护常规交换本身的补丁并没有成为主流。

所以，所有的一切：不。Linux仍然有差距。

UPD。：正如@ sourcejedi 指出的那样，有一个诸如dm-integrity之类的工具。从4.12版本开始的Linux内核已经成为了device-mapper的目标，可以将其用于为任何通用块设备提供校验和，并且那些用于交换的设备也不例外。该工具并未广泛集成到主要发行版中，并且大多数发行版都没有对udev子系统提供任何支持，但是最终这应该会改变。当与冗余提供程序（例如放在MD aka Linux软件RAID的顶部）配对时，不仅应该能够检测到比特腐烂，而且还可以将I / O请求重新路由到健康数据，因为dm-integrity会表明存在一个问题，MD应该处理。

我不认为这是一种“规范”的方式，因此以下是我个人的看法。

从潜在用户的角度监控了btrfs的发展之后，我不得不说，这仍然使我感到困惑。有些功能已经成熟并可以用于生产，有些功能似乎还不成熟，使用起来很危险。

就我个人而言，我没有时间决定要使用哪个功能，而不要决定使用哪个功能，请花些时间来确定如何关闭或打开这些功能。

相比之下，ZFS坚如磐石且成熟（IMHO）。因此，为回答您的问题，我将使用ZFS（顺便说一句，它不占用太多内存-见下文）。

但是对您而言，btrfs可能是正确的选择，因为您已经在使用它（如果我没看错），上面的注释之一显示了如何使用它进行交换。

碰巧的是，最近几天我在ZFS上放置了一些Linux服务器，每次包括根文件系统和交换。在我这样做之前，我已经非常彻底地进行了一些研究，这花了我几天的时间。我所学的简短摘要：

ZFS的内存消耗

关于ZFS的内存消耗，存在一个普遍的误解。ZFS一般也不会消耗太多的内存; 实际上，它在具有2 GB RAM的计算机上以TB的存储容量运行。仅当您使用重复数据删除（默认情况下处于关闭状态）时，它才需要大量的RAM。

硬件错误检测/纠正

SATA，PATA，RAID或其他错误检测/纠正机制是否足以保证数据完整性是一个引起无休止讨论的话题，甚至在网络上的各个地方都引发了火焰大战。从理论上讲，硬件存储设备应报告（并可能纠正）它遇到的任何错误，并且所有级别（芯片组，内存等）的数据传输硬件也应报告。

好吧，它们并不能在所有情况下都发挥作用，或者对错误做出令人惊讶的反应。作为示例，让我们以典型的RAID5配置为例。通常，如果一个磁盘有问题，它将报告给RAID，RAID进而构造要从其他磁盘读取的数据并将其继续传递，但也将其写回到故障磁盘（这可能会重新映射故障磁盘）。写入数据之前的扇区）；如果同一磁盘报告过多错误，则RAID会将其脱机并通知管理员（如果配置正确）。

到目前为止，还算不错，但是在某些情况下，有错误的数据会从磁盘中取出而磁盘没有报告错误（请参阅下一节）。大多数RAID可以使用奇偶校验信息来检测这种情况，但是它们的反应很愚蠢：它们不会报告错误并阻止数据继续传递，它们只是根据错误数据重新计算奇偶校验并将新的奇偶校验写入相应的奇偶校验中。磁盘，从而将错误数据永久标记为正确。

这是合理的行为吗？据我所知，大多数硬件RAID5控制器甚至Linux的md RAID都以这种方式运行。

我不了解btrfs的错误纠正，但是您最终应该再次仔细阅读文档，特别是如果您正在使用btrfs的RAID。

静音位腐烂

尽管进行了种种激烈的争论和（伪）科学讨论：现实大多与理论不同，并且尽管理论可能相反，但静默位腐烂肯定会发生（无声的机器人腐烂通常意味着硬件存储上的数据被破坏，而存储设备未报告读取此数据时发生错误，但我将在传输路径中的任何位置向此定义添加翻转位）。

发生这种情况并不是我个人的看法：至少Google，Amazon和CERN已经发布了涵盖该主题的详细白皮书。这些文件可免费公开下载。他们已经对数百万个硬盘和数十万个服务器/存储设备进行了系统的实验，或者是因为他们遇到了无法检测到的数据损坏问题，或者是因为他们想知道在发生故障之前应采取的预防措施。

总之，其服务器场中的数据被破坏的速度大大高于MTBF统计数据或其他理论所期望的速度。高得多，我的意思是数量级。

因此，无声的比特腐烂，即在传输路径中任何点都未检测到数据损坏，是一个现实生活中的问题。

数据寿命

沃伦·杨（Warren Young）说交换数据的寿命很短时是正确的。但我想补充以下考虑：不仅交换数据（从文档的角度而言），而且（也许更有可能）交换O / S或其他正在运行的软件的一部分。如果我有MP3可以交换，那我可以随便拿一点东西。如果（由于极端情况）我的生产httpd服务器软件的某些部分处于交换状态，则我绝不能忍受翻转位，如果没有检测到，稍后将导致执行损坏的代码。

结语

对我来说，ZFS解决了这些问题，或更准确地说，是将它们从磁盘移到内存中，从而将静默位腐烂的可能性降低了几个数量级。此外，如果配置正确（即使用镜像而不是RAID），它将提供干净合理的错误纠正，其效果与预期的一样，并且毕竟很容易理解。

话虽如此，请注意，您将永远无法获得绝对的安全。就个人而言，我对我的ECC RAM比对磁盘的信任度更高，而且我深信ZFS及其端到端校验和可以将问题发生的概率降低几个数量级。但是，我永远不建议使用没有ECC RAM的ZFS。

免责声明：我绝不与任何ZFS供应商或开发人员相关联。对于ZFS的所有变体（分支）都是如此。在过去的几天里，我只是成为它的粉丝...