PDF持久内存是否持久？
对故障原子更新机制的简单且廉价的测试
Terence Kelly
信任与验证
维护应用程序数据的完整性是计算系统的首要职责。诸如断电之类的故障是主要的危险：更新期间的突然崩溃可能会损坏数据，或者通过损坏元数据有效地破坏数据。应用程序通过使用相对于故障具有原子性的更新机制来保护数据完整性。这种机制承诺在崩溃后将数据恢复到应用程序定义的 一致状态，从而实现应用程序恢复。
不幸的是，故障原子更新机制的曲折历史排除了盲目信任。广泛使用的关系数据库和键值存储经常未能履行其事务性保证。24 在堆栈的较低层，耐用存储设备可能会在断电时损坏或破坏数据。25 新兴的NVM（非易失性存储器）硬件和相应的故障原子更新机制7,8 努力避免重蹈早期技术的覆辙，传统的硬件持久内存的软件抽象也是如此。10,11 然而，在任何新技术成熟之前，健康的怀疑态度都要求第一手证据来证明其兑现了完整性的承诺。
谨慎的开发人员遵循格言：“平时如何训练，战时就如何战斗。” 如果需求规定应用程序必须容忍指定的故障，那么应用程序应在预生产测试和/或生产系统上的游戏日故障注入测试中证明能够幸存下来。1 突然的全系统断电是对任何崩溃容错机制的最严峻挑战，并且没有替代广泛而真实的断电测试的方法。过去，我和我的同事测试了我们的崩溃容错机制以应对断电，3,17,20,21 但我们没有记录实践这门艺术所需的部落知识。
本文介绍了简单且经济高效的测试平台的设计和实现，该平台用于使在完整硬件/软件堆栈上运行的应用程序经受反复的突然全系统断电。完整的测试平台成本不到 100 美元，可以无限期无人值守运行，并在不到一分钟的时间内执行完整的测试周期。然后，该测试平台用于评估持久内存的最新崩溃容错机制。10 软件开发人员可以使用这种类型的测试平台来评估崩溃容错软件，然后再发布以供生产使用。应用程序操作员可以从本文中学习他们可以应用于断电测试其生产硬件和软件的原则和技术。
当然，仅断电测试只是整体可靠性和可靠性保证链条中的一环。可靠性取决于周到的设计和仔细的实施；保证取决于尽可能地进行验证以及各种各样且彻底的实际测试。2,13 本文介绍的技术以及其他补充的保证措施，可以帮助勤奋的开发人员和操作员保护应用程序数据的安全。
本文的其余部分组织如下：下一节简要回顾持久内存和相应的崩溃容错机制，重点介绍本文稍后将测试的软件。随后的部分描述了断电测试平台以及持久内存崩溃容错机制的测试结果。本文中描述的所有软件都可以在 https://queue.org.cn/downloads/2020/Kelly_powerfail.tar.gz 获取。
持久内存
虽然非易失性内存是一种硬件类型，但持久内存是一种更通用的、与硬件无关的抽象，它允许在缺少 NVM 的传统计算机上实现。11 相应的持久内存编程风格涉及在内存映射文件中布局应用程序数据结构，允许应用程序逻辑通过 CPU 指令 (LOAD 和 STORE) 直接操作持久数据。
持久内存编程的主要吸引力在于其简单性：它既不需要单独的外部持久存储（如关系数据库），也不需要在内存数据格式和不同的持久性格式之间进行转换。传统硬件上持久内存的另一个好处是存储灵活性。持久应用程序数据最终驻留在文件中，并且可以完全自由地选择文件系统下方的持久存储层：即使持久应用程序数据必须跨高可用性弹性云存储进行异地复制，应用程序仍然可以通过 LOAD 和 STORE 访问它。毫不奇怪，各种形式的持久内存正受到行业和软件从业人员越来越多的关注。16
传统硬件上持久内存的正确崩溃容错机制是 FAMS（故障原子 msync()）。17 传统的 Posix msync() 系统调用将文件支持的内存映射的修改页面推送到后备文件中，但在出现故障时没有任何完整性保证，而 FAMS 保证后备文件的状态始终反映最近成功的 msync() 调用。FAMS 允许应用程序将持久数据从一个一致状态演变为下一个一致状态，而无需担心因意外崩溃而损坏。我和我的同事已经在 Linux 内核17、商业文件系统20 和用户空间库9,23 中实现了 FAMS。至少还存在两个独立的 FAMS 实现。4,5,22 虽然本文重点介绍类似 Posix 的环境，但在其他操作系统上存在类似的功能。例如，Microsoft Windows 具有类似于 mmap() 的接口，并实现了故障原子文件更新机制。17
本文使用下一节中描述的断电测试平台来评估最新的 FAMS 实现：famus_snap（通过快照在用户空间中实现故障原子 msync()）。10 famus_snap 实现旨在易于审计。之前的 FAMS 实现要么涉及神秘的内核/文件系统代码，要么涉及数百行用户空间代码，而 famus_snap 的代码量只有 51 行非空白的简单代码，不包括注释。它通过利用 BtrFS、XFS 和 OCFS2 文件系统中目前可用的高效的按文件快照功能来实现简洁。12 在文件快照之上构建 FAMS 的一个附带好处是效率：快照采用写时复制机制，因此避免了日志记录的双重写入。20 虽然原则上 famus_snap 看起来非常清晰简洁，其正确性可以通过检查来评估，但实际上，其正确性取决于文件系统快照功能的实现，因此有必要进行全系统断电测试。
断电测试平台
断电测试平台最重要的要求是，在主机上运行的软件必须能够在自己选择的时间突然切断主机的电源。然后必须以某种方式恢复主机的电源，主机必须通过重新启动并开始下一个测试周期来响应。主机计算机应该坚固耐用，能够承受数千次断电，并且应该能够快速执行断电/上电循环。它还应该为预算有限的开发人员所能承受，并且应该足够便宜以至于可以消耗，因为重复的电源循环压力最终可能会损坏它。实际上，您应该更愿意使用最脆弱的硬件：根据定义，这种硬件会增加测试失败的可能性，因此在廉价机器上成功的测试最能激发信心。本节的其余部分描述了主机计算机、辅助电路和软件，它们共同实现了这些目标。
主机计算机
选择一台好的主机计算机并非易事。从云提供商处租用将满足节俭的目标，但不幸的是，云硬件被虚拟化层层包裹，以至于根据设计，客户软件无法物理断开裸机的电源。高端服务器公开了管理接口，允许远程重启或关机，但这种关机比突然断电要温和得多；如果您可以以某种方式突然切断高端服务器的电源，则可能会损坏昂贵的机器。笔记本电脑价格便宜且随处可见，但笔记本电脑缺乏 BIOS 功能来在外部电源恢复时触发自动重启。工作站和台式 PC 具有这种 BIOS 功能，但它们笨重、耗电且启动缓慢。
诸如 Raspberry Pi 之类的单板计算机非常适合我们的目的：它们体积小、坚固耐用、价格便宜到可以消耗，并且功耗非常低。Pi 运行 Linux 操作系统和几乎所有 Linux 软件。它在通电时快速且自动启动。它的 GPIO（通用输入/输出）引脚使非特权软件可以方便地控制外部电路。最重要的是，它是一台极简主义的朴实机器。如果软件和存储设备通过了 Pi 上的断电测试，那么它们在更昂贵的、功能更丰富的硬件上可能也不会更差。本文中的测试平台使用 Raspberry Pi 3 Model B+，该型号将至少生产到 2026 年。18
单板计算机的主要缺点是 CPU 功能和外围接口的限制。例如，Pi 3B+ CPU 不支持 Linux “软脏位”，并且存储仅限于板载 microSD 卡和 USB 连接的设备。但是，可以通过例如 SATA 到 USB 适配器连接各种存储设备。总的来说，对于当前目的而言，单板计算机的吸引力超过了其局限性。
断电电路
过去，我和我的同事使用带有网络控制接口的交流电源排插来测试我们的崩溃一致性机制。3,17,20,21 这些电源排插往往很挑剔且文档记录不完善。我们之前的测试系统包括一台单独的控制计算机，以及一台托管被测软件和存储设备的计算机；控制机器使用电源排插来切断和恢复主机的电源。事后看来，这些早期的测试框架似乎不必要地复杂，很像“买车只是为了听收音机”。本节中描述的极简主义断电电路更便宜、更优雅、支持更严格的测试，并使主机可以直接控制断电。
此处介绍的测试平台使用机电继电器来物理断开主机计算机的电源。继电器忠实地模拟了突然断电的效果，并完全隔离了主机。
电源电路可能包含令人惊讶的剩余能量，足以使即使是服务器级计算机也能在市电电源故障时稍微优雅地关机。15 因此，我们的断电电路位于主机计算机及其电源之间，这消除了电源中的剩余能量可能以某种方式使主机有序关机而不是突然停止的可能性。
事实证明，一个非常简单的电路就足以瞬间断开主机计算机的电源，从而可靠地触发立即重启。图 1 所示的电路围绕单稳态（非锁存）继电器构建。当足够的电流激励继电器的线圈时，可移动极从其常闭位置切换到其常开位置。（图 1 遵循许多继电器数据表上找到的约定：常闭触点显示为最靠近线圈，您需要想象线圈中的电流将继电器的极向上推向常开触点。）我们使用一个继电器19，其触点可以承载 Pi 的足够功率，并且其线圈可以通过 Pi 的 3.3 伏 GPIO 引脚操作，而不会超过其 16 毫安的电流限制。继电器的 180Ω 线圈，以及 GPIO 引脚的 31Ω 内阻14，适当地限制了电流。
如图 1 所示，Pi 的电源通过继电器的常闭触点布线。当 Pi 上的软件使用 GPIO 引脚来激励继电器的线圈时，随着继电器的极从常闭触点跳开，Pi 的电源被切断。然后，现在断电的 Pi 上的 GPIO 引脚停止向线圈推送电流，因此极迅速落回常闭位置，从而恢复 Pi 的电源并触发重启。当电流停止流过继电器线圈时，线圈中的磁场会崩溃，释放的能量可能会损坏控制 GPIO 引脚的 Pi 上的精细电路。与继电器线圈并联连接的常用保护二极管可防止此类损坏。（有关感性负载的二极管保护的描述，请参见《电子艺术》6。我的电路使用 IN4001 二极管。）
围绕图 1 电路的主要担忧是它非常快速地恢复了主机的电源，这可能会以某种方式掩盖更长的断电时间会暴露的故障。
图 2 显示了第二个电路，称为 PiNap，它可以中断 Pi 的电源几秒钟。
如图 2(a) 所示，该电路包括两个电容器：一个有助于切换继电器，另一个在 Pi 断电时接管激励继电器线圈的角色。图 2(b) 描述了正常运行：外部 5.1 V 电源通过继电器的常闭触点向 Pi 供电；它还为两个电容器充电。图 2(c) 显示了瞬态情况，因为主机计算机上的软件通过 GPIO 引脚激励继电器的线圈：外部电源立即与主机断开，但来自电容器 C2 的能量使 GPIO 引脚能够将继电器的极完全向上推，以闭合常开触点。然后，如图 2(d) 所示，电容器 C1 通过线圈放电，使 Pi 断电几秒钟。当 C1 中的能量耗尽时，继电器的极落回常闭触点，从而恢复 Pi 的电源，Pi 重新启动以进行下一个测试周期。
简单的计算确定了 PiNap 电路中所有组件的规格。继电器与图 1 电路中的继电器相同，原因相同。19 电容器 C1 充电至 5.1 V，因此您首先选择电阻器以将继电器线圈上的电压降降低至约 3 V；根据欧姆定律，120Ω 是合适的。现在您选择 C1，使得 C1 和电阻器的 RC（电阻-电容）时间常数约为几秒钟；10–40 毫法 (10,000–40,000 μF) 范围内的任何值都可以。此范围内的电解电容器非常笨重——大致相当于盐瓶的大小——因此我使用小得多的 22,000 μF 超级电容。最后，电容器 C2 必须能够保持足够的能量，以在继电器的极在飞行中（根据继电器数据表，约为一毫秒）保持线圈通电；220 μF 或更大即可。
图 3 显示了面包板上的 PiNap 的特写镜头。继电器是中心附近的白色盒子。电容器 C2 是右边缘的圆柱体；右上角的黑色矩形是超级电容 C1。电阻器和保护二极管分别是垂直和水平方向的小圆柱体。所有组件都舒适地安装在照片底部的美国四分之一美元硬币上，并且完整的电路占据了扑克牌大小的面包板的上半部分。主机计算机的 GPIO 和接地引脚分别通过继电器两侧的红色和黑色垂直跳线连接。外部 5.1 V 电源通过面包板两侧的内导轨进入面包板，并通过外导轨退出。
一些继电器和电容器需要正确的直流极性；我的也是如此。以错误的方式通过极性敏感继电器线圈发送电流将无法切换极，并且保护二极管将提供短路路径。不正确的极性可能会导致极化电容器发生故障。组装电路时，请密切注意极性。
图 4 显示了美国信纸大小的方格纸上的完整测试平台：PiNap 面包板位于底部中心，带有 USB 连接存储设备的 Raspberry Pi 位于右侧，电源位于左侧。为了清晰起见，已移除 Pi 的 USB 鼠标和键盘。为了将 PiNap 置于电源和 Pi 之间，我剪断了电源线，并将面包板友好的 22 AWG 实心铜线焊接到其绞合线上；这是组装测试平台硬件中最慢的一步。图 4 中显示的所有内容都可以以低于 100 美元的价格购买。
构建此测试平台的两个最终提示
• 首先，继电器的引脚行间距太近，无法跨越面包板的中心凹槽，因此我用绕线插座制作了一个适配器（在图 3 中继电器和面包板之间可见）。我也尝试过将电线夹紧和/或焊接到继电器的引脚上，但图 3 中所示的临时适配器更整洁，并且似乎不太可能损坏继电器。
• 其次，某些 Raspberry Pi 3B+ 的 GPIO 引脚上的输出电压在启动期间会波动。断电电路需要一个引脚，该引脚在 Pi 上运行的软件将其设置为输出逻辑“高电平”（3.3 V）之前保持在零伏特。物理引脚 40 非常适合作为 GPIO 输出引脚，物理引脚 39 提供零伏特接地。这些引脚最靠近 Pi 的 USB 端口；请参阅图 4 中的跳线。
为了简洁和美观，本文省略了我在图 1 和图 2 的电路之前设计和构建的第三个断电电路。它使用了两个继电器、一个集成电路定时器芯片、几个电阻器、电容器和二极管，以及一个单独的 12 VDC 电源，除了 Pi 的 5.1 V 电源。我的第一个电路在数千次测试中可靠地工作，并且在某些方面它比 PiNap 更容易解释，但它比本文中介绍的电路成本更高、更复杂且更难组装。我的第一个电路的主要贡献是展示了过度简化，从而激发了寻找更精简替代方案的努力。
系统配置和测试软件
配置主机计算机和测试软件以测试 famus_snap 库以应对断电的细节有些繁琐。本节提供了测试设置过程的简要高级摘要。详细说明是随本文提供的源代码 tarball 的一部分。（有抱负的读者：以默认用户“pi”身份登录到您的 Pi，在主目录 /home/pi/ 中解压，并查看 README 文件。）
主机硬件配置相对简单。主机计算机必须通过 GPIO 和接地引脚连接到图 1 或图 2 的外部电路，Pi 的电源通过该电路布线。存储设备通过 Pi 的 USB 端口之一连接。请注意，配置主机进行测试会销毁存储设备上的所有数据。
主机计算机软件配置涉及几个步骤。主机运行 Linux 的 Raspbian 变体；我使用了 2018 年和 2019 年的几个版本的操作系统。必须安装几个非默认软件包，特别是 xfsprogs，它用于在 USB 连接的存储设备上创建新的 XFS 文件系统。使用 XFS 是因为 famus_snap 依赖于高效的 reflink 快照，而 XFS 是少数支持此功能的文件系统之一。可以将 Pi 配置为以精简方式启动（例如，不启动图形用户界面）。精简启动可能会更快，但差异很小，默认启动速度足够快（不到一分钟）。
示例代码 tarball 包含特定于 famus_snap 测试的其他软件。主要的断电测试程序称为 pft。它将后备文件映射到内存中，反复用特殊的伪随机模式填充内存中的映像，并调用 famus_snap 模拟的 msync() 以将内存中的映像提交到快照文件。这些测试的目标是查看断电是否会损坏 pft 的应用程序级别数据；因此，伪随机模式的设计使得损坏易于检测。
设置 cron 实用程序以在每次 Pi 启动时运行一个名为 rab 的脚本，当外部电路恢复电源时会发生这种情况。rab 的主要工作是调用测试脚本 pft_run。脚本 pft_run 启动测试程序 pft，等待几秒钟，然后使用 GPIO 引脚激活外部电路，该电路切断并恢复 Pi 的电源。
rab 脚本支持断电测试的替代方案：它可以用于在 pft 运行时突然重启 Pi，这比断电压力小，但更容易设置，因为外部电路是不必要的。
在完成适当数量的开/关循环后，您可以检查 pft 的数据是否已损坏，方法是运行 check 脚本。check 脚本在恢复模式下运行 pft，这会检查适当的快照文件，以查看它们是否包含预期的伪随机模式。
结果
famus_snap 的测试使用了本文中讨论的所有三个外部断电电路：图 1 和图 2 的电路以及之前简要提及的第三个复杂电路。测试在三个不同的存储设备上运行：一个廉价（30 美元）的 64 GB 闪存 U 盘；一个据称坚固且相当昂贵（220 美元）的 512 GB 闪存记忆棒；以及一个价格适中（90 美元）的 500 GB 便携式 SSD（固态驱动器）。总共运行了超过 58,000 个断电/上电测试周期。每个断电/上电周期大约需要一分钟，这比我和我的同事过去构建的测试环境的五分钟周期时间要快得多。3,17,20,21 所有测试都完美通过；没有损坏单个字节的数据。
检查测试留下的残骸可以了解被测软件在断电时正在做什么。当应用程序软件调用其 msync() 替代品时，famus_snap 库会创建后备文件的快照；调用者选择快照文件名并决定何时删除它们。pft 测试应用程序在两个快照文件之间交替；famus_snap 的规则规定，崩溃后恢复应将后备文件替换为最新的可读快照文件。10
在一个为期一个月的测试运行中，使用昂贵的闪存记忆棒完成了 49,626 个断电/上电测试周期，断电使快照文件对处于所有四种逻辑可能的情况下：仅存在一个快照文件，并且它适合恢复（0.054% 的测试）；两个文件都存在且已满（即，与后备文件大小相同），但只有一个可读（4.7%）；两个快照文件都已满且可读，因此恢复必须比较它们的上次修改时间戳（43.8%）；一个文件已满且可读，但另一个文件大小不足且可写（51.4%）。
这些结果符合我的预期，这是基于 pft 应用程序和 famus_snap 库在不同状态下花费的相对时间量。改变测试覆盖范围平衡的一种方法是从 pft 应用程序或 famus_snap 库内部触发断电，类似于 famus 库9 中使用的内联“崩溃点”测试（不要与 famus_snap 混淆）。
正如 Dijkstra 著名地指出的那样，测试可以显示 bug 的存在，但不能显示 bug 的不存在。我的结果并不能证明 famus_snap 将始终坚持其数据完整性保证，也不能证明 Raspbian 操作系统、XFS 文件系统、Raspberry Pi 计算机或经过测试的存储设备在电源故障下是可靠的。我只能报告这些工件没有利用无数次令人失望的机会。在 famus_snap 这样的极简库和 Pi 这样的适度硬件上取得的成功进一步提高了功能齐全、昂贵的硬件和/或软件的标准。在服务器级主机和企业级存储上运行的商业关系数据库最好能够完美地承受数万次突然的全系统断电——否则供应商需要做出一些解释！
总结与结论
断电对应用程序数据完整性构成最严重的威胁，而痛苦的经验教训表明，故障原子更新机制的完整性承诺不能被视为理所当然。勤奋的开发人员和操作员坚持通过广泛的第一手测试来确认完整性声明。本文介绍了一个简单且廉价的测试平台，能够每周对存储设备、系统软件和应用程序软件进行数万次突然的全系统断电测试。
最近实现的故障原子 msync() 的 famus_snap 版本以优异的成绩通过了数万次断电测试，这表明硬件/软件堆栈的所有组件——测试应用程序代码、famus_snap 库代码、XFS 文件系统、操作系统、存储设备和主机计算机——要么按预期运行，要么非常幸运。
未来的工作可能会调整本文的技术，以围绕其他类型的单板计算机（例如，基于其他 CPU 类型的计算机）设计测试平台。可以说，未来工作最重要的方向是部署和广泛应用针对声称在出现故障时保持数据完整性的工件的彻底的压力测试套件。具有讽刺意味的是，事务处理系统的性能基准比比皆是，但崩溃一致性测试套件却相对罕见，就好像速度比正确性更重要一样。本文的技术和研究文献24 中的方法已经确定了有效的测试策略。现在是时候将这些知识付诸实践了。
参考文献
1. Allspaw, J. 2012. 生产环境中的故障注入。acmqueue 10(8); https://queue.org.cn/detail.cfm?id=2353017.
2. Alvaro. P., Tymon, S. 2017. 将天才从故障测试中抽象出来。acmqueue 15(5); https://queue.org.cn/detail.cfm?id=3155114.
3. Blattner, A., Dagan, R., Kelly, T. 2013. Indigo 及更高版本的通用崩溃弹性存储。惠普实验室技术报告 HPL-2013-75; http://www.hpl.hp.com/techreports/2013/HPL-2013-75.pdf.
4. Hellwig, C. 2017. 文件系统和块设备的故障原子写入。 https://lwn.net/Articles/715918/.
5. Hellwig. C. 2019. Linux 的故障原子文件更新。Linux Piter 2019 会议; 演示文稿: https://linuxpiter.com/en/materials/2307; 补丁: https://www.spinics.net/lists/linux-xfs/msg04536.html and http://git.infradead.org/users/hch/vfs.git/shortlog/refs/heads/O_ATOMIC.
6. Horowitz, P., Hill, W. 2015. 电子艺术，第三版，第 38-39 页和 818 页。剑桥大学出版社。
7. 英特尔。傲腾技术; http://www.intel.com/optane/.
8. 英特尔。持久内存开发工具包; http://pmem.io/pmdk/.
9. Kelly, T. famus: 用户空间中的故障原子 msync()。 http://web.eecs.umich.edu/~tpkelly/famus/.
10. Kelly, T. 2019. 好的老式持久内存。;login: 44(4), 29-34; https://www.usenix.org/system/files/login/articles/login_winter19_08_kelly.pdf. (famus_snap 库的源代码可在 https://www.usenix.org/sites/default/files/kelly_code.tgz 获取。)
11. Kelly, T. 2019. 传统硬件上的持久内存编程。acmqueue 17(4); https://dl.acm.org/citation.cfm?id=3358957.
12. Linux 程序员手册。ioctl_ficlone(); http://man7.org/linux/man-pages/man2/ioctl_ficlonerange.2.html.
13. McCaffrey, C. 2016. 分布式系统的验证。acmqueue 13(9); https://queue.org.cn/detail.cfm?id=2889274.
14. McManus, S., Cook, M. 2015. Raspberry Pi，第二版，281 页。John Wiley & Sons 出版社。
15. Narayanan, D., Hodson, O. 2012. 全系统持久性。第 17 届编程语言和操作系统架构支持会议 (ASPLOS) 会议论文集; https://dl.acm.org/doi/proceedings/10.1145/2150976
16. Swanson, S.（组织者）。现实生活中的持久编程（会议）; https://pirl.nvsl.io/.
17. Park, S., Kelly, T., Shen, K. 2013. 故障原子 msync()：一种用于保持持久数据完整性的简单高效机制。第 8 届 欧洲计算机系统会议 (EuroSys) 会议论文集; https://dl.acm.org/citation.cfm?id=2465374.
18. Raspberry Pi 3 Model B+; https://www.raspberrypi.org/products/raspberry-pi-3-model-b-plus/.
19. TE Connectivity。Axicom 继电器，产品代码 IM21TS，部件号 1-1462039-5。供应商数据表: https://www.te.com/usa-en/product-1-1462039-5.html; https://www.te.com/usa-en/product-1-1462039-5.datasheet.pdf; https://www.te.com/commerce/DocumentDelivery/DDEController?Action=srchrtrv&DocNm=1-1773734-7_IM_Relay_I_Type&DocType=DS&DocLang=English.
20. Verma, R., Mendez, A. A., Park, S., Mannarswamy, S., Kelly, T., Morrey, B. 2015. Linux 文件系统中应用程序数据的故障原子更新。载于第 13 届 Usenix 文件和存储技术会议 (FAST)；https://www.usenix.org/system/files/conference/fast15/fast15-paper-verma.pdf。
21. Verma, R., Mendez, A. A., Park, S., Mannarswamy, S., Kelly, T., Morrey, B. 2015. SQLean：通过原子文件更新加速数据库。技术报告 HPL-2015-103，惠普实验室；http://www.labs.hpe.com/techreports/2015/HPL-2015-103.pdf。
22. Xu, J., Swanson, S. 2016. NOVA：用于混合易失性/非易失性主内存的日志结构文件系统。载于第 14 届 Usenix 文件和存储技术会议 (FAST)；https://www.usenix.org/system/files/conference/fast16/fast16-papers-xu.pdf。
23. Yoo, S., Killian, C., Kelly, T., Cho, H. K., Plite, S. 2012. 异步系统的可组合可靠性。Usenix 年度技术会议。https://www.usenix.org/conference/atc12/technical-sessions/presentation/yoo。
24. Zheng, M., Tucek, J., Huang, D., Qin, F., Lillibridge, M., Yang, E. S., Bill W. Zhao, B. W., Singh, S. 2014. 为了乐趣和利益而折磨数据库。载于第 11 届 Usenix 操作系统设计与实现研讨会 (OSDI)；https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-zheng_mai.pdf（请注意，错误表另行提供。）
25. Zheng, M., Tucek, J., Qin, F., Lillibridge, M. 2013. 了解 SSD 在电源故障下的鲁棒性。载于第 11 届 Usenix 文件和存储技术会议 (FAST)；https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf。
相关文章
传统硬件上的持久内存编程
持久内存编程风格可以显著简化应用程序软件。
Terence Kelly
https://queue.org.cn/detail.cfm?id=3358957
生产环境中的故障注入
为弹性测试辩护
John Allspaw，Etsy
https://queue.org.cn/detail.cfm?id=2353017
从故障测试中抽象出天才
普通用户需要工具来自动化定制故障选择以进行注入。
Peter Alvaro 和 Severine Tymon
https://queue.org.cn/detail.cfm?id=3155114
Terence Kelly
版权所有 © 2020，归所有者/作者所有。出版权已授权给 。
最初发表于 Queue vol. 18, no. 2—
在 数字图书馆 中评论本文
© 保留所有权利。