PDF保障比特安全：到底有多难？
随着存储系统变得越来越大，长期存储的数据保护也变得越来越具有挑战性。
David S. H. Rosenthal，斯坦福大学
如今，我们都是数据囤积者。存储很便宜，所以只要数据有可能有用，我们就会保留它。我们知道存储并非完全可靠，因此我们也会保留备份副本。但是，我们保留的数据越多，保留的时间越长，当我们需要数据时，其中一些数据将无法恢复的可能性就越大。
我们应该问一个显而易见的问题：我们需要在具有何种可靠性的存储系统中保留多少个副本，才能获得给定的概率，确保在我们需要数据时能够恢复数据？ 这可能是一个显而易见的问题，但令人惊讶的是，这个问题很难回答。让我们看看原因。
具体来说，假设我们需要将 1 PB 的数据保存一个世纪，并有 50% 的概率保证每个比特都能完好无损地保存下来。这听起来可能有很多数据和很长时间，但已经有一些数据集合比 1 PB 更大，并且需要永久保存。“互联网档案”就已经有数 PB 的数据。
关于保障比特安全方面的知识现状可以总结为：
• 副本越多，越安全。 随着数据规模的增加，每个副本的成本也会增加，从而减少了可以负担的备份副本数量。
• 副本越独立，越安全。随着数据规模的增加，可负担的存储技术也越来越少。因此，相同存储技术中的副本数量增加，从而降低了平均独立性水平。
• 副本审计的频率越高，越安全。 随着数据规模的增加，每次审计检测和修复损坏所需的时间和成本也会增加，从而降低了审计频率。
声明
乍一看，将 1 PB 的数据保存一个世纪并不难。存储系统制造商对其产品的声明远远超过了我们需要的可靠性。例如，Sun 声称其 ST5800 Honeycomb 产品的 MTTDL（平均数据丢失时间）为 2.4×106 年。a,41 现成的解决方案看起来非常可靠，以至于备份都是不必要的。我们应该相信这些声明吗？ 它们从何而来？
在使用 Sun 对 ST5800 的声明作为示例之前，我应该声明 ST5800 是一款优秀的产品。它代表了存储技术的先进水平，而 Sun 的营销声明也代表了存储营销的先进水平。然而，Sun 并没有保证 ST5800 中的数据可以保存 2.4×106 年。Sun 的条款和条件明确声明，对于 ST5800 存储的数据发生的任何损失或损坏，Sun 概不负责40，无论何时发生。
Sun 所说的只是，如果您长时间观察大量 ST5800 系统，记录每个系统首次发生数据丢失的时间，然后对这些时间取平均值，结果将是 2.4×106 年。假设 Sun 观察了 10 个 ST5800，并注意到其中 3 个在第一年丢失了数据，其中 4 个在 2.4×106 年后丢失了数据，其余 3 个在 4.8×106 年后丢失了数据；Sun 声称 MTTDL 为 2.4×106 年是正确的。但我们不会认为数据丢失的概率在第一年就达到 30% 的系统足以安全地保存 1 PB 的数据一个世纪。单个 MTTDL 数字并非对解决方案的有用描述。
让我们看看天狼星网络公司营销部门最近发布的 SC5800 时提出的稍微更科学的声明：b “SC5800 的 MTTDL 为 (2.4±0.4)×106 年。” 天狼星网络公司隐含地假设故障呈正态分布，因此声称大约三分之二的故障将发生在实验开始后 2.0×106 年到 2.8×106 年之间。它并没有在 280 万年前开始观察一批 SC5800，那么天狼星网络公司是如何知道的呢？
天狼星网络公司表示，它每年将销售 2×104 个 SC5800，每个售价 5×104 美元（每年 10 亿美元的业务），并且预计该产品将在市场上销售 10 年。SC5800 的使用寿命为 10 年。因此，如果天狼星网络公司在其整个使用寿命内观察 SC5800 的全部产量（价值 1010 美元的存储系统），则实验将在 20 年后结束，届时将积累约 2×106 系统年的数据。如果其声明是正确的，天狼星网络公司将有大约 17% 的机会看到单个数据丢失事件。
换句话说，天狼星网络公司声称没有 SC5800 会丢失任何数据 的概率超过 80%。或者，由于每个 SC5800 存储 5×1013 字节，因此有 80% 的概率，1019 字节的数据将在 10 年内完好无损地保存下来。
如果有人可以相信天狼星网络公司的声明，那么 1 PB 的数据在一个世纪内看起来将非常安全。但即使天狼星网络公司的声明是基于实际实验，它也不会提供 20 年的结果，即使提供了，也不会验证所提出的数字。事实上，像 Sun 和天狼星网络公司这样的声明根本不是实验的结果。任何可行的实验都无法验证它们。它们是基于系统组件（如磁盘和软件）行为模型的预测。
模型
这种建模技术的先进水平以加州大学圣克鲁兹分校的 Pergamum 项目39 为例。其模型包括从测量35, 30 得出的磁盘故障率和从磁盘供应商规范得出的扇区故障率。该系统试图通过尽可能地停止磁盘旋转来节省电力；它考虑了这样做对磁盘寿命的影响，但尚不清楚这种考虑是基于什么。Pergamum 团队报告说，模拟很困难
“数据的缺乏是由于这些配置的极高可靠性——模拟器模拟了许多故障，但很少有故障导致数据丢失，因此模拟运行非常缓慢。这种行为正是我们希望从归档存储系统中获得的：它可以优雅地处理许多故障事件而不会丢失数据。即使我们捕获的三重交叉奇偶校验配置的数据点较少，我们相信报告的 MTTDL 是一个合理的近似值。”39
尽管 Pergamum 团队为获得其系统 MTTDL 的“合理近似值”所做的努力值得称赞，但有许多理由相信，它在实践中高估了系统的可靠性
• 该模型从指数分布中提取其故障。因此，该团队假设磁盘和扇区故障都是不相关的，尽管所有实际故障的观察5, 42 都报告了显着的相关性。相关的故障大大增加了数据丢失的可能性。6, 13
• 除了每次启动事件导致磁盘寿命略有缩短之外，Pergamum 团队还假设在始终开启的磁盘使用情况下观察到的故障率可以转化为大部分时间都关闭的环境。Pergamum 论文之后发表的一项研究43 报告了对几乎总是关闭的磁盘的数据保留进行了定量的加速寿命测试。它表明，Pergamum 团队预期的某些 3.5 英寸磁盘在这种使用模式下的数据寿命比使用相同磁头和盘片技术的 2.5 英寸磁盘的数据寿命差得多。
• 该团队假设磁盘和扇区故障是导致系统故障的唯一故障，尽管一项研究17 表明，其他硬件组件也做出了重大贡献。
• 它假设其软件没有错误，尽管对文件和存储实现的多项研究20, 14, 31 一致报告在所有研究的系统中都发现了可能导致数据丢失的错误。
• 它还忽略了对存储数据的其他所有威胁34，例如可能导致数据丢失的原因。其中包括操作员错误、内部人员滥用和外部攻击。这些都成为了实际数据丢失的传闻报告的主题。
此类模型可以告诉我们什么？ 它们的结果取决于以下两个方面：
• 所研究系统的模拟细节，我们希望这些细节能够准确反映其行为。
• 用于驱动模拟的数据，我们希望这些数据能够准确反映系统组件的行为。
在某些条件下，使用这些模型来比较不同的存储系统技术是合理的。最重要的条件是，两个系统的模型使用相同的数据。如果用于模拟系统 A 的数据中磁盘驱动器等组件的故障率远低于用于模拟系统 B 的数据，那么声称建模显示系统 A 比系统 B 更可靠的说法是不可信的。
这些模型很可能是评估用于防止数据丢失的不同技术的最佳工具，但它们不足以回答我们的问题。我们需要知道数据丢失的最大速率。这些模型假设了一些事情，例如不相关的错误和没有错误的软件，但所有真实世界的研究都表明这些是错误的。这些模型排除了存储数据所面临的大部分威胁。在那些类似声明（例如磁盘可靠性声明35, 30）已经过测试的情况下，它们已被证明是乐观的。因此，这些模型提供了对最小预期数据丢失率的估计。
指标
即使我们相信这些模型，MTTDL 数字也无法告诉我们平均数据丢失事件中丢失了多少数据。MTTDL 为 106 年的 PB 级系统 A 是否比 MTTDL 为 103 年的类似大小的系统 B 更好？如果系统 A 中的平均数据丢失事件丢失了整个 PB 的数据，而系统 B 中的平均数据丢失事件丢失了 1 KB 的数据，那么很容易证明系统 B 比系统 A 好 109 倍。
平均数据丢失时间并不是衡量系统随时间推移存储比特效果的有用指标，因为它与时间有关，但与比特无关。磁盘制造商通常引用的 UBER（不可恢复的比特错误率）也不是一个有用的指标；它是指比特被错误读取的概率，而不管它在磁盘上已经存储了多长时间。它与比特有关，但与时间无关。因此，我们看到我们甚至缺乏回答问题所需的指标。
为了更清楚地了解情况，让我们过度简化问题。假设我们消除了所有可能导致相关数据丢失的来源，从操作员错误到过热。剩下的只有比特衰减，这是一个随机翻转系统存储的比特的过程，每单位时间的概率都很小。在这个模型中，我们可以将比特视为放射性原子，因此，比特发生翻转的概率达到 50% 的时间就是比特半衰期。
1 PB 的数据保存一个世纪并有 50% 概率存活的要求转化为 8×1017 年的比特半衰期。目前对宇宙年龄的估计为 1.4×1010 年，因此这是一个大约为宇宙年龄 6×107 倍的比特半衰期。
这个比特半衰期要求清楚地表明了我们给自己设定的问题有多么困难。假设我们想知道我们正在考虑购买的系统是否足够好，能够满足 1 PB 数据保存一个世纪并有 50% 概率存活的要求。即使我们绝对相信除了比特衰减之外的所有数据丢失来源都已完全消除，我们仍然必须对系统的比特半衰期进行基准测试，以确认它是否长于宇宙年龄的 6×107 倍。而且这个基准测试必须在一年左右的时间内完成；它不能花费一个世纪。
因此，我们购买 103 个与我们想要购买的系统完全相同的系统，在每个系统中写入 1 PB 的数据，这样我们总共就有 1 EB 的数据，等待一年，将这 1 EB 的数据读回，然后进行检查。如果系统刚刚好，我们可能会看到 5 个比特翻转。或者，由于比特衰减是一个随机过程，我们可能会看到更多或更少。我们需要比 1 EB 多得多的数据，或者需要比一年多得多的时间，才能合理地确定比特半衰期足够长，能够胜任这项工作。但即使是 1 EB 的数据保存一年，成本也是我们想要购买的系统的 10 倍。
这个思考实验告诉我们，我们现在正在处理如此大量的比特，时间又如此之长，以至于我们永远不会知道我们使用的系统是否足够好
• 已知的数据丢失原因太多，而且相关性太高，模型无法产生可信的预测。
• 即使我们忽略所有这些原因，为了合理地确定随机比特衰减不重要所需的实验也太昂贵，或者花费的时间太长，或者两者兼而有之。
测量故障
直到 2007 年，研究人员才开始发布关于实际大规模存储系统在实践中提供的可靠性的研究报告。谷歌9 等企业和斯隆数字巡天37 和大型强子对撞机8 等机构都在收集具有长期价值的 PB 级数据，这些数据必须保持在线才能有用。每年保持 1 PB 数据在线的成本超过 100 万美元。27 很容易理解为什么存储系统的经济性和可靠性问题成为研究人员关注的焦点。
2007 年 FAST（文件和存储技术）会议上的论文使用了来自 NetApp35 和 Google30 的数据，研究了大型存储集群中的磁盘更换率。他们表明，制造商的 MTTF 数字是乐观的。随后对 NetApp 数据的分析17 表明，所有其他组件都对存储系统故障做出了贡献，并且
“有趣的是，[早期的研究] 发现磁盘更换的频率远高于（2-4 倍）供应商指定的[更换率]。但正如这项研究表明的那样，除了磁盘故障之外，还有其他存储子系统故障被视为磁盘故障，并导致不必要的磁盘更换。”17
两项研究，一项在 CERN（欧洲核子研究组织）18 进行，一项使用来自 NetApp 的数据5，大大改进了早期使用来自互联网档案的数据所做的工作。6, 36 他们研究了静默数据损坏——存储中文件的内容在没有任何解释或记录错误的情况下发生更改的事件——在最先进的存储系统中。
NetApp 的研究调查了 RAID 阵列中单个磁盘中静默存储损坏的发生率。数据收集了 41 个月，来自 NetApp 在现场的文件服务器，涵盖了超过 1.5×106 个驱动器。该研究发现了超过 4×105 起静默损坏事件。其中超过 3×104 起事件直到 RAID 恢复时才被检测到，因此可能导致数据丢失，尽管 NetApp 的行对角奇偶校验 RAID 提供了复制和审计。11
CERN 的研究使用了一个程序，该程序将大文件写入 CERN 的各种数据存储中，这些数据存储代表了各种最先进的企业存储系统（主要是 RAID 阵列），并在六个月的时间内对其进行了检查。总共写入了约 9.7×1016 字节，发现约 1.92×108 字节发生了静默损坏，其中约三分之二是持久性的；重新读取没有返回好的数据。换句话说，写入 CERN 存储的数据中约有 1.2×10-9 在六个月内永久损坏。我们可以通过假设数据在六个月开始时立即写入，并在结束时立即检查来对当前存储系统样本中的比特半衰期设置上限；结果为 2×108，约为宇宙年龄的 10-2 倍。因此，为了达到 1 PB 数据保存一个世纪的要求，我们需要将当前企业存储系统的性能提高至少 109 倍。
容忍故障
尽管制造商声称如此，但当前的研究表明，最先进的存储系统远远低于我们的比特保存要求，以至于我们不能期望即使技术取得巨大进步也能弥补这一差距。在单个存储系统中维护单个副本并不是解决比特保存问题的充分解决方案。
因此，实用的数字保存系统必须：
• 通过在多个（理想情况下是不同的）存储系统上复制其数据来维护多个副本。
• 审计（或擦洗）副本以检测损坏，并通过用另一个副本中的数据覆盖已知损坏的副本来修复损坏。
副本越多，审计和修复的频率越高，我们可以预期的比特半衰期就越长。毕竟，这是常用的备份和校验和技术的基础。事实上，当前的存储系统已经内部使用了此类技术——例如，以 RAID 的形式。29 尽管如此，它们提供的比特半衰期仍然不足。不幸的是，添加必要的存储系统间复制和擦洗成本很高。
来自圣地亚哥超级计算机中心c 2008 年的成本数据显示，每年维护一个 1 PB 数据的在线副本的成本约为 1.05×106 美元。磁带上的单个近线副本每年花费约 4.2×105 美元。这些成本随着时间的推移而降低，尽管不如原始磁盘成本下降得快。英国图书馆估计每年下降 30%。假设这个速度至少持续十年，如果您可以负担得起第一年成本的约 3.3 倍来额外存储一个副本十年，那么您就可以负担得起无限期地存储它。因此，在磁盘上添加 1 PB 数据的第二个副本将花费约 3.5×106 美元，在磁带上花费约 1.4×106 美元。以这种方式增加保存工作的成本以提高可靠性是一把双刃剑：这样做必然会增加因经济原因导致保存失败的风险。
此外，在不详细了解不同机制导致丢失和损坏的速率的情况下，仍然无法回答我们最初提出的问题，也无法知道需要多少个副本才能使我们达到所需的安全性，从而也无法知道必要复制的成本。在小规模上，对此不确定性的反应是添加更多副本，但随着规模的增加，这很快就会变得无法承受。
在相同系统之间复制比在不同系统之间复制的效果差得多。相同系统容易受到共模故障的影响——例如，由所有系统中损坏每个系统中的相同数据的软件错误引起的故障。另一方面，购买和运营多个相同系统将比运营一组不同系统便宜得多。
每个副本都容易丢失和损坏。除非定期审计，否则它们对增加比特半衰期几乎没有贡献。擦洗数据所需的带宽和处理能力都很昂贵，并且增加这些成本会增加失败的风险。定制硬件25 可以在一个月内计算出 1 PB 数据的 SHA-128 校验和，但这样做需要令人印象深刻的带宽——相当于三个千兆以太网接口在一个月内全速运行。用户对长期存储数据的访问通常不频繁；因此，它很少被设计为提供如此高带宽的读取访问。系统成本随着 I/O 带宽的增加而迅速增加，并且擦洗所需的对数据的额外访问（无论是在磁盘上还是在磁带上）本身可能会增加失败的风险。
以这种方式编写软件来读取和验证数据系统存储数据的目的是检测损坏并利用系统间的复制来修复损坏，从而增加比特半衰期。我们能做得多好？ RAID 是应用于磁盘的此类软件技术的一个示例。在实践中，CERN 对外部真实 RAID 系统进行的研究18 显示了显着的静默数据损坏率，而 NetApp 对内部真实 RAID 系统进行的研究5 显示了显着的静默磁盘错误率，这将导致静默数据损坏。对用于实现 RAID 的全套当前算法的研究20 发现了所有算法中导致潜在数据丢失的缺陷。这项研究和 IBM 的另一项研究16 都提出了对 RAID 算法的改进，但两者都没有声称它可以消除静默损坏，甚至无法准确预测其发生率
“虽然我们尝试使用尽可能真实的概率数字，但目标不是提供精确的数据丢失概率，而是说明使用模型检查器的优势，并讨论不同保护方案之间的潜在权衡。”20
因此，尽管系统间复制和擦洗能够降低数据丢失的发生率，但它们无法完全消除数据丢失。而且复制和擦洗软件本身将包含可能导致数据丢失的错误。我们是否能够充分实施这些技术，从而在可负担的副本数量下将系统的比特半衰期提高 109 倍，这一点令人怀疑。
神奇的介质
考虑到磁盘驱动器技术面临的困难，12 存储系统实现的可靠性令人震惊，但这显然还不够。新闻网站定期报道一些关于某种新型存储介质已经解决了长期数据存储问题的说法。声称可以持续 1000 年的合成石材 DVD23 就是最近的一个例子。这些说法应该像 Sun 和其他存储系统制造商的说法一样受到怀疑。相关介质可能确实比其竞争对手更可靠，但正如我们所见，原始介质的可靠性只是故事的一部分。我们的 1 PB 数据将是一堆 2×105 个石材 DVD。这么大的一堆东西在 100 年内可能会发生很多事情。真正完全可靠的神奇介质会让问题变得更好，但它们不会完全消除问题。
我记得磁泡存储器，所以我有一种似曾相识的感觉，但闪存，或者可能是更奇特的固态技术，如忆阻器或相变存储器，开始看起来有可能取代磁盘。这些技术有很多优点，适合长期存储，但它们会提高存储可靠性吗？
同样，我们尚不知道答案。尽管闪存无处不在，但甚至还不清楚如何测量其 UBER
“UBER 值可能远好于 10-15，但 UBER 是程序/擦除循环和后续保持时间的强函数，因此 UBER 规范必须与这些数量的最大规范相结合。”26
换句话说，这取决于您如何使用它，而磁盘的情况似乎并非如此。用于长期数据存储的闪存（写入一次，读取频率较低）原则上应该表现非常好。从硬盘驱动器切换到闪存的系统级影响可能令人印象深刻
“FAWN [wimpy 节点快速阵列] 将低功耗嵌入式 CPU 与少量本地闪存存储相结合，并平衡计算和 I/O 能力，以实现对数据的高效、大规模并行访问。 ...FAWN 集群每焦耳能量可以处理大约 350 个键值查询——比基于磁盘的系统高出两个数量级。”3
快速 CPU、快速 RAM 和快速磁盘都消耗大量功率，因此 FAWN 的低功耗并不令人意外。但高性能来自磁盘发展的另一个方面。表 1 显示了读取各种代系的最先进磁盘的全部内容需要多长时间。
磁盘变得越来越大，但它们的速度并没有同等程度地提高。这是可以预期的；数据速率取决于比特直径的倒数，但容量取决于比特面积的倒数。FAWN 节点可以非常快速地读取其全部内容，这对于擦洗以及回答查询都很有用。
这一切都令人鼓舞，但一旦有可能大规模研究磁盘存储的行为，系统级可靠性就明显远低于介质规范。这应该让我们对预测闪存或任何其他新的存储技术带来的革命保持谨慎。
经济学
自从克莱顿·克里斯坦森出版了《创新者的困境》10 以来，每两年磁盘驱动器的每字节成本减半已成为常识。因此，您可能会认为，您不需要知道需要多少个副本才能长期保证数据的安全，您只需要知道在未来几年内需要多少个副本才能保证数据的安全。之后，您可以保留更多副本。
事实上，正在发生的事情是，恒定成本下的容量每两年翻一番，这与每字节成本减半并不完全相同。只要这种指数增长速度快于您生成新数据的速度，随着时间的推移添加副本就是一个可行的策略。
唉，指数曲线可能会具有欺骗性。摩尔定律一直在不断推出越来越小的晶体管。然而，几年前，它实际上停止了提供越来越快的 CPU 时钟频率。事实证明，从商业角度来看，与使单个 CPU 更快相比，将额外的晶体管用于更重要的事情。例如，将多个 CPU 放在一个芯片上。
在最近的一次国会图书馆会议上，希捷的戴夫·安德森警告说4，类似的事情即将发生在硬盘驱动器上。HAMR（热辅助磁记录）和 BPM（比特图案化介质）等技术已经到位，可以交付 2013 年的磁盘产品（即，容量为 8 TB 的消费级 3.5 英寸驱动器）。但构建它的商业案例很薄弱。特别是向 BPM 过渡的成本令人望而生畏。24 笔记本电脑、上网本以及现在的平板电脑正在摧毁 3.5 英寸驱动器所用台式电脑的市场。很少有消费者会填满 2009 年的 2 TB 磁盘产品，那么拥有 8 TB 驱动器有什么价值呢？更不用说如何在您的办公桌上备份 8 TB 驱动器的问题了！
可能发生的情况——实际上，已经发生的情况——是消费市场将相当快地过渡到 2.5 英寸驱动器。这将消除高容量的 100 美元 3.5 英寸驱动器，因为它将不再以消费级数量生产。消费者仍将购买 100 美元的驱动器，但它们将是 2.5 英寸的，容量可能只有三分之一。在一段时间内，每字节成本曲线充其量会趋于平缓，更有可能上升。这带来的问题是，大规模磁盘集群目前由消费级 3.5 英寸驱动器构建。市场中的现有参与者已经重注指数成本下降将继续下去；如果他们错了，那将是颠覆性的。
更大的图景
我们无法计算出为了达到可靠性目标需要多少备份副本，这是我们不得不接受的现实。实际上，我们不会有足够的备份副本，东西会丢失或损坏。这本不应该令人惊讶，但不知何故却成了事实。比特可以被正确复制这一事实导致了人们期望比特总是会被正确复制，进而期望数字存储是可靠的。 在此认知与人们数字存储的实际体验之间存在着奇怪的认知失调，即丢失和损坏是司空见惯的22。
存储的可靠性不足以让我们忽视故障问题，这仅仅是计算领域随着规模不断扩大而面临的更大问题的一个方面。当前长期运行的百亿亿次级高性能计算机应用程序需要复杂且昂贵的检查点和重启方案，因为执行期间发生故障的概率非常高，从头开始重启是不可行的。 这种方法将无法扩展到即将到来的下一代
“……预计百亿亿次级系统每天会经历多次各种类型的故障。还预计，目前依赖自动或应用程序级检查点-重启的弹性方法将无法奏效，因为检查点和重启的时间将超过整个系统的平均故障间隔时间。……”
“一些预测估计，按照当前技术，检查点和重启的时间可能在 2015 年之前超过顶级超级计算机的平均中断时间。这不仅意味着计算几乎无法取得进展；还意味着故障处理协议必须处理多个错误——当前的解决方案通常设计为处理单个错误。”7
正如存储一样，组件和互连的数量非常庞大，以至于故障发生率很高，而可用带宽相对较低，以至于从故障中恢复需要很长时间，必须处理多种故障情况。 没有实用且经济实惠的方法可以向应用程序屏蔽故障。 应用程序员将需要更加关注检测和从其环境中的错误中恢复。 为此，他们既需要 API，也需要实现这些 API 的系统环境变得更加具有故障意识。
API 增强
存储 API 正开始朝着这个方向发展。 最新的存储服务接口2 允许应用程序的写入调用不仅提供指向数据的指针和长度，还可以选择性地提供应用程序的数据消息摘要。 这使得存储系统能够检测数据在从应用程序到设备的传输过程中，或在存储设备中，或在复制回应用程序的过程中是否损坏。 最近的研究表明，应用程序和存储设备之间的内存缓冲区44 和数据路径17 对错误有很大影响。
让我们以 Amazon S3（简单存储服务）REST API2 为例，说明虽然这些发展值得欢迎，但它们远非万能药。PUT请求支持可选（且推荐）的 Content-MD5（消息摘要算法 5）标头，其中包含应用程序的数据摘要。 对大多数请求的响应，包括PUT，都包含带有服务对象 MD5 的 ETag（实体标签）标头。 应用程序可以记住在PUT之前计算出的摘要，并在PUT返回时，验证服务摘要是否匹配。
这样做是一个明智的预防措施，但这实际上只是告诉应用程序，服务知道应用程序认为正确的摘要是什么。 服务知道这个摘要，不是因为它计算了正确数据的摘要，而是因为应用程序在 Content-MD5 标头中提供了它。 恶意的或发生故障的服务可能会正确响应PUT和HEAD请求，通过记住应用程序的摘要，而无需存储数据或计算其摘要。
应用程序可以尝试通过使用GET来获取存储的数据，计算返回数据的摘要 (a)，并将其与 (b) 响应的 ETag 标头中的摘要或它在原始PUT之前计算并记住的摘要（两者应该相同）进行比较，从而检测恶意的或发生故障的服务。 似乎有两种情况：如果两个消息摘要匹配，则数据正常；d 否则就不是。 实际上有四种情况，如表 2 所示，具体取决于摘要 (b) 是否更改。 这四种情况说明了两个问题
• 构成摘要的比特与构成数据的比特没有区别；两者都没有神奇地不可破坏。 恶意的或发生故障的服务可能会返回错误的数据，其 ETag 标头中的摘要与数据匹配，但不是最初计算的摘要。 应用程序需要知道摘要是否已更改。 Haber 等人15 描述了一个在没有不可破坏的存储的情况下执行此操作的系统。
• 鉴于 Amazon S3 等云存储服务的定价结构，定期提取整个数据以确认其是否正确存储过于昂贵。 需要一种由服务计算数据摘要的方法，但仅仅要求服务返回存储对象的摘要不足以进行检查。33 必须挑战服务，证明其对象是好的。 最简单的方法是要求服务计算 nonce（一个随机比特串）和对象的摘要；由于服务无法预测 nonce，因此正确的响应需要在收到请求后访问数据。 Maniatis 等人21 和 Shah 等人38 描述了使用此技术的系统。
早期检测是一件好事：检测和修复之间的时间越短，第二次错误会危及修复的风险就越小。 但检测只是解决方案的一部分；系统还必须能够修复损坏的数据。 只有当系统在其他地方复制了数据——并且某些重复数据删除层没有优化掉这种复制时，它才能做到这一点。
结论
如果能以乐观的调子结束，描述一些技术修复方案，使应用程序能够忽略其环境中，特别是长期存储中发生故障的可能性，那就太好了。 不幸的是，在现实世界中，故障是不可避免的。 随着系统规模的扩大，故障变得更加频繁。 即使投入资金来解决问题，也只能减少故障的发生率，而不能完全排除故障。 未来的应用程序将需要更加意识到故障，并认真应对故障。
高性能计算社区准确地描述了需要做什么
“我们已经提到软件层之间在错误和故障管理方面缺乏协调。 目前，当软件层或组件检测到故障时，它不会以一致的方式通知系统上运行的其他软件部件。 因此，此软件组件采取的故障处理措施对系统的其余部分是隐藏的。 ……在理想的世[界]中，如果软件组件检测到潜在错误，则信息应传播到可能受错误影响的其他组件，或控制可能导致错误的资源的组件。”7
特别是，关于存储，API 应该效仿 Amazon 的 S3，提供可选的数据完整性功能，允许应用程序执行端到端检查。 应该增强这些 API，以允许应用程序提供一个可选的 nonce，该 nonce 在报告给应用程序的消息摘要计算之前被添加到对象数据的前面。 这将允许应用程序排除报告的摘要是被记住而不是重新计算的可能性。
问
致谢
衷心感谢 Eric Allman、Kirk McKusick、Jim Gettys、Tom Lipkis、Mark Compton、Petros Maniatis、Mary Baker、Fran Berman、Tsutomu Shimomura 和已故的 Jim Gray。 部分材料最初在 iPRES 2008 上展示，随后在International Journal of Digital Curation32 中发表。
错误和遗漏由作者本人承担。 这项工作由 LOCKSS 联盟的成员图书馆以及美国国会图书馆的国家数字信息基础设施和保护计划资助。
注释
a. 数字以 10 的幂表示法表示，以帮助读者关注问题的规模和所需的非凡可靠性水平。
b. 为本星系的贵族和绅士提供喋喋不休的门、存在主义电梯和偏执狂机器人的供应商。1
c. 2007 年的数据在 Moore 等人27 中。
d. 假设摘要算法没有被破解，对于 MD5 来说，这不是一个安全的假设。19
参考文献
1. Adams, D. 1978. The Hitchhiker's Guide to the Galaxy. British Broadcasting Corp.
2. Amazon. 2006. Amazon S3 API 参考（3 月）。； http://docs.amazonwebservices.com/AmazonS3/latest/API/。
3. Andersen, D. G., Franklin, J., Kaminsky, M., Phanishayee, A., Tan, L., Vasudevan, V. 2009. FAWN：一个快速的弱节点阵列。 在 SIGOPS 第 22 届操作系统原理研讨会论文集 中：1-14。
4. Anderson, D. 2009. 硬盘驱动器方向（9 月）； http://www.digitalpreservation.gov/news/events/other_meetings/storage09/docs/2-4_Anderson-seagate-v3_HDtrends.pdf。
5. Bairavasundaram, L., Goodson, G., Schroeder, B., Arpaci-Dusseau, A. C., Arpaci-Dusseau, R. H. 2008. 存储堆栈中的数据损坏分析。 在第 6 届 Usenix 文件和存储技术会议论文集中。
6. Baker, M., Shah, M., Rosenthal, D. S. H., Roussopoulos, M., Maniatis, P., Giuli, TJ, Bungale, P. 2006. 重新审视长期数字存储的可靠性。 在EuroSys2006 会议论文集（4 月）中。
7. Cappello, F., Geist, A., Gropp, B., Kale, S., Kramer, B., Snir, M. 2009. 面向百亿亿次级弹性的研究。 技术报告 TR-JLPC-09-01。 INRIA-伊利诺伊州百亿亿次级计算联合实验室（7 月）。
8. CERN. 2008. 全球 LHC 计算网格； http://lcg.web.cern.ch/LCG/。
9. Chang, F., Dean, J., Ghemawat, S., Hsieh, W. C., Wallach, D. A., Burrows, M., Chandra, T., Fikes, A., Grube, R. E. 2006. Bigtable：用于结构化数据的分布式存储系统。 在第 7 届 Usenix 操作系统设计和实现研讨会论文集中：205-218。
10. Christensen, C. M. 1997. 创新者的困境：当新技术导致伟大的公司失败时。 剑桥，马萨诸塞州：哈佛商学院出版社（6 月）。
11. Corbett, P., English, B., Goel, A., Grcanac, T., Kleiman, S., Leong, J., Sankar, S. 2004. 用于双磁盘故障纠正的行对角线奇偶校验。 在第 3 届 Usenix 文件和存储技术会议（3 月）中。
12. Elerath. J. 2009. 硬盘驱动器：好的、坏的和丑陋的。 Communications of the 52(6)。
13. Elerath, J. G., Pecht, M. 2007. RAID 存储系统增强的可靠性建模。 在第 37 届 IEEE/IFIP 国际可靠系统和网络会议论文集中：175-184。
14. Engler, D. 2007. 系统黑客速成课程：在真实（存储）系统代码中发现大量错误的技术。 在第 5 届 Usenix 文件和存储技术会议论文集（2 月）中。
15. Haber, S., Stornetta, W. S. 1991. 如何为数字文档加盖时间戳。 Journal of Cryptology 3(2): 99-111。
16. Hafner, J. L., Deenadhayalan, V., Belluomini, W., Rao, K. 2008. RAID 阵列中未检测到的磁盘错误。 IBM Journal of Research & Development 52(4/5)。
17. Jiang, W., Hu, C., Zhou, Y., Kanevsky, A. 2008. 磁盘是存储故障的主要贡献者吗？ 存储子系统故障特征的综合研究。 在第 6 届 Usenix 文件和存储技术会议论文集中。
18. Kelemen, P. 2007. 静默损坏。 在第 8 届 Linux 超级计算集群年度研讨会中。
19. Klima, V. 2005. 查找 MD5 冲突——笔记本电脑的玩具。 密码学电子预印本存档，报告 2005/075； http://eprint.iacr.org/2005/075。
20. Krioukov, A., Bairavasundaram, L. N., Goodson, G. R., Srinivasan, K., Thelen, R., Arpaci-Dusseau, A. C., Arpaci-Dusseau, R. H. 2008. 奇偶校验丢失和奇偶校验恢复。 在第 6 届 Usenix 文件和存储技术会议论文集中。
21. Maniatis, P., Roussopoulos, M., Giuli, TJ, Rosenthal, D. S, H, Baker, M., Muliadi, Y. 2003. 通过速率限制采样投票来保护对等副本。 在第 19 届 操作系统原理研讨会论文集中：44-59（10 月）。
22. Marshall, C. 2008. “就像一场火灾。 你只需要继续前进”：重新思考个人数字存档。 在第 6 届 Usenix 文件和存储技术会议中。
23. Mearian, L. 2009. 初创公司声称其 DVD 可持续使用 1,000 年。 Computerworld（11 月）。
24. Mellor, C. 2010. 驱动器供应商遇到容量增加困难。 The Register（7 月）。
25. Michail, H. E., Kakarountas, A. P., Theodoridis, G., Goutis, C. E. 2005. SHA-1 哈希函数的低功耗和高吞吐量实现。 在第 9 届 WSEAS 国际计算机会议论文集中。
26. Mielke, N., Marquart, T., Wu1, N., Kessenich, J., Belgal, H., Schares, E., Trivedi, F., Goodness, E., Nevill, L. R. 2008. NAND 闪存中的误码率。 在第 46 届国际可靠性物理学研讨会中：9-19。
27. Moore, R. L., D'Aoust, J., McDonald, R. H., Minor, D. 2007. 磁盘和磁带存储成本模型。 在2007 年存档中。
28. 国家标准与技术研究院 (NIST)。 1995. 联邦信息处理标准出版物 180-1：安全哈希标准 (SHA-1)（4 月）。
29. Patterson, D. A., Gibson, G., Katz, R. H. 1988. 低成本磁盘冗余阵列 (RAID) 的案例。 在 SIGMOD 国际数据管理会议论文集中：109-116（6 月）。
30. Pinheiro, E., Weber, W.-D., Barroso, L. A. 2007. 大型磁盘驱动器群体中的故障趋势。 在第 5 届 Usenix 文件和存储技术会议论文集（2 月）中。
31. Prabhakaran, V., Agrawal, N., Bairavasundaram, L., Gunawi, H., Arpaci-Dusseau, A. C., Arpaci-Dusseau, R. H. 2005. IRON 文件系统。 在第 20 届操作系统原理研讨会论文集中。
32. Rosenthal, D. S. H. 2010. 比特保存；一个已解决的问题？ International Journal of Digital Curation 1(5)。
33. Rosenthal, D. S. H. 2010. LOCKSS：大量副本确保安全。 在NIST 数字保存互操作性框架研讨会（3 月）中。
34. Rosenthal, D. S. H., Robertson, T. S., Lipkis, T., Reich, V., Morabito, S. 2005. 数字保存系统的需求：自下而上的方法。 D-Lib Magazine 11(11)。
35. Schroeder, B., Gibson, G. 2007. 真实世界中的磁盘故障：1,000,000 小时的 MTTF 对您意味着什么？ 在第 5 届 Usenix 文件和存储技术会议论文集（2 月）中。
36. Schwarz, T., Baker, M., Bassi, S., Baumgart, B., Flagg, W., van Imngen, C., Joste, K., Manasse, M., Shah, M. 2006. Internet Archive 的磁盘故障调查。 在NASA/IEEE 大容量存储系统和技术会议的工作进展会议中。
37. SDSS（斯隆数字巡天）2008 年； http://www.sdss.org/。
38. Shah, M. A., Baker, M., Mogul, J. C., Swaminathan, R. 2007. 审计以保持在线存储服务的诚实性。 在第 11 届热点操作系统研讨会（5 月）中。
39. Storer, M. W., Greenan, K. M., Miller, E. L., Voruganti, K. 2008. Pergamum：用节能、可靠、基于磁盘的归档存储取代磁带。 在第 6 届 Usenix 文件和存储技术会议论文集中。
40. Sun Microsystems. 2006. 销售条款和条件，第 11.2 节（12 月）； http://store.sun.com/CMTemplate/docs/legal_terms/TnC.jsp#11。
41. Sun Microsystems. 2008. ST5800 演示文稿。 Sun PASIG 会议（6 月）。
42. Talagala, N. 1999. 大型存储系统的表征：错误行为和性能基准。 博士论文，加州大学伯克利分校计算机科学系（10 月）。
43. Williams, P., Rosenthal, D. S. H., Roussopoulos, M., Georgis, S. 2008. 预测可移动硬盘驱动器的归档寿命。 在2008 年存档（6 月）中。
44. Zhang, Y., Rajimwale, A., Arpaci-Dusseau, A. C., Arpaci-Dusseau, R. H. 2010. 文件系统的端到端数据完整性：ZFS 案例研究。 在第 8 届 Usenix 文件和存储技术会议中。
喜欢它，讨厌它？ 让我们知道
David Rosenthal 在硅谷担任工程师四分之一个世纪，包括在 Sun Microsystems 担任杰出工程师，并在 NVIDIA 担任第 4 号员工。 在过去的十年里，他一直在斯坦福大学图书馆的支持下研究长期数字保存问题。
版权归作者所有
最初发表于 Queue 杂志第 8 卷，第 10 期—
在 数字图书馆 中评论这篇文章
更多相关文章
Pat Helland - 关注您的状态，了解您的心境
随着应用程序进入分布式和可扩展的世界，它们经历了有趣的发展。 同样，存储及其近亲数据库也与应用程序并肩发展。 很多时候，存储和应用程序的语义、性能和故障模型在不断变化的业务需求和环境挑战的支持下，都在进行着微妙的舞蹈。 将规模添加到混合中确实激起了波澜。 本文着眼于其中的一些问题及其对系统的影响。
Alex Petrov - 现代存储系统背后的算法
本文仔细研究了现代数据库中使用的两种存储系统设计方法（读取优化的 B 树和写入优化的 LSM（日志结构合并）树），并描述了它们的使用案例和权衡取舍。
Mihir Nanavati, Malte Schwarzkopf, Jake Wires, Andrew Warfield - 非易失性存储
对于大多数从业计算机科学家的整个职业生涯来说，一个基本的观察结果一直成立：CPU 的性能和成本都明显高于 I/O 设备。 CPU 可以极高的速率处理数据，同时为多个 I/O 设备提供服务，这一事实对各种规模系统的硬件和软件设计产生了广泛的影响，几乎在我们构建它们以来就一直是这样。
Thanumalayan Sankaranarayana Pillai, Vijay Chidambaram, Ramnatthan Alagappan, Samer Al-Kiswany, Andrea C. Arpaci-Dusseau, Remzi H. Arpaci-Dusseau - 崩溃一致性
数据的读取和写入是任何冯·诺依曼计算机最基本的方面之一，但却出奇地微妙且充满细微差别。 例如，考虑在具有多个处理器的系统中访问共享内存。 虽然称为强一致性的简单直观方法最容易让程序员理解，但许多较弱的模型也得到广泛使用（例如，x86 总存储顺序）； 这种方法提高了系统性能，但代价是使系统行为的推理更加复杂且容易出错。
© 保留所有权利。