BenchCouncil交易基准，标准和评估1（2021）100006可观察性的基准测试：诊断存储故障的案例张铎，麦政美国爱荷华州立大学电气与计算机工程系A R T I C L E I N F O关键词：存储系统故障诊断可观测性可再现性可靠性鲁棒性基准测试跟踪记录和重放A B S T R A C T诊断存储系统故障即使对于专业人员来说也是一项挑战。最近的一个例子是在Algolia数据中心发生的“当固态硬盘不是那么坚固”事件，三星SSD被错误地归咎于Linux内核错误引起的故障。随着系统复杂性的不断增加，故障诊断可能会变得更加困难。为了更好地了解现实世界中的故障和最先进的工具的潜在局限性，我们首先进行了实证研究277用户报告的存储故障在本文中。我们将这些问题沿着多个维度（例如，解决时间、涉及的核心组件），这提供了对实践中的挑战的定量测量。此外，我们深入分析了一组的存储问题，并得出一个基准套件，称为存储存储器。基准测试套件包括再现9个存储故障所需的工作负载和软件环境，涵盖4个不同的文件系统和存储堆栈的块I/O层，并支持对各种内核级工具进行实际评估以进行调试。为了演示使用方法，我们应用程序调试工具来研究两个有代表性的调试工具。 我们专注于测量工具使开发人员能够进行的观察（即，可观测性），并推导出具体的度量来定性和定量地测量可观测性。我们的测量演示了不同的设计权衡调试信息和开销。更重要的是，我们观察到这两种工具在应用于诊断一些棘手的病例时可能会表现异常。此外，我们发现，这两种工具都不能提供有关持久存储状态如何改变的低级信息，这对于理解存储故障是至关重要的。为了解决这一限制，我们开发了轻量级扩展，以便在这两个工具中启用此类功能。我们希望，故障诊断和启用的测量将激发后续的基准测试和工具支持研究，并帮助解决故障诊断的挑战1. 介绍Linux内核中的存储堆栈正在见证由非易失性存储器（NVM）技术的进步驱动的巨变[1例如，SCSI子系统和Ext4文件系统已经为硬盘驱动器（HDD）优化了几十年，分别为基于闪存的固态驱动器（SSD）和持久性存储器（PM）添加了多队列支持[14-虽然这样的修改可以提供更高的性能一般，对系统可靠性的影响是很少测量或理解。一个现实世界的例子是在Algolia数据中心发生的“开发人员“花了两周的时间隔离机器并尽快恢复数据”。在尝试诊断堆栈中的几乎所有软件（例如，Ext4，软件RAID [19]），他们最终（错误地）得出结论，这是三星三星∗ 通讯作者。一个月后，三星的工程师发现，这是一个与TRIM相关的Linux内核错误导致的失败[20]。在可预见的未来，随着系统复杂性的不断增加，类似的混乱故障可能会增加[21应对这一重大挑战将需要各社区作出一致努力。其中，更好地了解现实世界的故障事件和最先进工具的潜在局限性至关重要。为此，本文首先对277个实际存储故障问题进行了实证研究。我们沿着多个维度（例如，解决时间、涉及的内核组件、硬件依赖性），这使我们能够定量地测量可靠性挑战以及对更好解决方案的需求。此外，我们深入分析了一组存储问题。通过仔细检查用户报告和错误补丁，并在实际存储系统上进行实验，我们得出了必要的条件（例如，用户/工作负载操作、库/内核版本、系统配置），用于确定性地触发故障在这个时候电子邮件地址：duozhang@iastate.edu（D. Zhang），mai@iastate.edu（M.Zheng）。https://doi.org/10.1016/j.tbench.2021.100006接收日期：2021年8月6日;接收日期：2021年10月11日;接受日期：2021年10月20日2021年11月12日网上发售2772-4859/©2021作者。Elsevier B. V.代表KeAi Communications Co. Ltd.提供的出版服务。这是CC BY-NC-ND许可证下的开放获取文章（http://creativecommons.org/licenses/by-nc-nd/4.0/）。可在ScienceDirect标准和评价期刊主页：https://www.keaipublishing.com/en/journals/benchcouncil-transactions-on-benchmarks-standards-and-evaluations/BenchCouncil交易基准，D. Zhang和M. 郑BenchCouncil交易基准，标准和评估1（2021）1000062我们成功地重现了九个案例，涵盖了四种不同的文件系统以及Linux存储堆栈的低级块I/O层。基于可重现的案例，我们创建了一个基准测试套件，该软件包含一组可移植的虚拟机（VM）映像，其中包含所有必要的软件程序和环境，以重现由内核级错误引起的九次存储故障。���1作为现有基准套件的补充，这些基准套件主要是为测量性能而设计的[26-������������������������内核错误检测器[30，31]、跟踪器[32]、记录重放工具[33]），这对于识别潜在的限制以及进一步改进的机会至关重要。为了演示使用方法，我们利用调试工具来分析两个代表性的调试工具：（1）FTrace，Linux内核内部跟踪器[32];和（2）PANDA，基于VM的记录重放工具[33]。���与现有研究主要测量工具的运行时开销[ 34 ]不同虽然可观测性的基本概念并不新[35]，但我们推导出一组具体的度量，以定量和/或定性地测量可观测性，我知道了我们的实验证明了不同的设计权衡在调试信息和空间开销方面的工具。 更重要的是，我们发现有多个棘手的故障情况下，这两个工具可能无法正常工作。换句话说，工具的使用可能会对目标存储堆栈引入干扰，并使故障症状不可再现。此外，我们发现这两种工具都不能直接提供低级信息（例如，存储设备命令），这对于理解存储堆栈中的主机-设备交互至关重要。为了解决这一限制，我们探索了不同的方法来扩展FTrace和PANDA，并表明可以在不依赖特殊硬件的情况下用这种低水平的可观测性来增强它们（例如，总线分析器[36，37]）。众所周知，有效的基准测试套件和工具对于改进各种计算机系统至关重要;另一方面，构建有效的基准测试套件和工具是一个长期的迭代过程，需要广泛的社区共同努力[25，34，38]。据我们所知，这项工作是第一次努力基准调试工具的可观察性与具体的指标。我们希望这台机器的原型和最初的努力���本文所演示的方法将启发后续的基准测试和工具支持可靠性的研究，并有助于提高计算机系统的整体性能。2本文的其余部分组织如下：在第2节中，我们描述了背景和扩展动机;在第3节中，我们描述了现实世界的存储故障并推导出存储故障的可观测性;在第4节中，我们基于������������������������������������������������在第5节中，我们将讨论相关的工作;最后，我们在第6节结束论文。2. 背景动机2.1. 存储堆栈可靠性挑战图1显示了典型的存储堆栈，3传统上包括几个主要层，如文件系统、块I/O层和设备驱动程序。最近引入的PM技术可以提供比DRAM少3倍的访问延迟，同时保持耐用性[1]巧合的是，有一个关于应用程序级BugBench的早期工作[25];我们在第5节中详细说明了差异和协同作用。2 我们 释放 ���������������������ℎ��� 公开 对 GitLab：https://git.ece.iastate.edu/数据存储实验室/原型/bugbench。3改编自SNIA NVM编程模型[39]。Fig. 1. 存储堆栈。内核级软件模块（绿色）是这项工作的主要重点。来源：改编自[39]。guarantee [40]，它模糊了内核中存储管理和内存管理因此，内存管理子系统也成为持久数据存储堆栈的一部分。存储系统是出了名的复杂和难以得到正确的，尽管几十年的努力[41此外，近年来，存储堆栈中的几乎所有层都在积极优化。例如，SSD和PM正在取代HDD作为耐用设备[10-scsi-mq [14-F2FS [49]，NOVA [50]，Kevlar [51]），其中一些需要在整个存储堆栈中进行内聚修改（例如，TRIM支持[52]）。这种修改可能会引入各种软件错误，导致系统故障[41，53]。在实践中，存储故障可能由于各种原因而发生，包括但不限于软件错误[41然而，尽管有各种各样的轶事，但很少有定量测量或了解现实世界中我们试图在这项工作中解决这个问题2.2. 调试工具已经建立了许多工具来提高系统的可靠性。例如，测试工具（例如，模型检查器[41]、模糊器[30，31，57]、故障注入器[58-然而，一旦系统在实践中发生故障，由于不同的环境和假设，测试工具可以帮助查明根本原因。另一类是调试工具，其目的是在实践中发生故障后便于诊断根本原因。虽然包含真实案例的基准测试套件可用于评估测试工具和调试工具，但本文重点关注调试工具，因为：（1）与测试工具的大量工作相比，它们的研究要少得多;（2）它们在诊断真实世界的故障事件中非常需要。我们将现有的调试工具分为以下三类交互式绘图器。这一类别包括经典的调试器，如GDB/KDB/KGDB[62- 64 ]，它代表了实际上的方式，D. Zhang和M. 郑BenchCouncil交易基准，标准和评估1（2021）1000063诊断软件系统故障。它们通常支持细粒度的手动检查（例如，在特定语句处设置断点，检查特定内存字节的值）。然而，需要大量的人力和专业知识来有效地利用电力和诊断复杂的存储堆栈。这种传统的调试方法可以说是不可扩展的，因为随着系统变得越来越复杂，所需的手动工作和经验将不断增加。可能需要更多的自动化和/或智能来使调试可扩展。软件硬件跟踪器。软件跟踪器[32，65- 跟踪的日志可以帮助理解系统异常（以及其他目的），这对于故障诊断通常是非常宝贵的。同样，总线分析- ER [36，37]是可以捕获低级通信数据（例如，SCSI命令[70]）。然而，由于它们只跟踪总线级的信息，所以它们对理解系统级的行为没有多大帮助。录制回放工具。记录重放工具[33，71]已经被应用于用户级应用程序和内核的调试。通常，这些工具利用虚拟机来运行作为一个整体的目标软件栈。同时，它们记录系统快照以及非确定性事件（例如，中断），以确保忠实地重放系统执行。开发人员可以重复回放记录的整个系统执行日志，而无需重新运行工作负载。此外，可以将记录重放工具与交互式调试器（例如， GDB）来执行传统的调试（例如，设置断点）。还可以基于记录重放机制（例如，PANDA中的插件[33]）。请注意，上述三种类型的工具都是在实践中广泛使用的重要调试工具。但据我们所知，很少有定量测量他们的调试能力。我们试图解决这项工作中的不足之处。我们专注于软件跟踪器和记录回放工具，因为它们可以实现不同程度的故障诊断自动化，我们相信对于可扩展的调试方法至关重要。我们把交互式调试器（这需要难以量化的手动努力/专业知识）和硬件跟踪器（这需要特殊的硬件）的测量作为未来的工作。2.3. 调试工具一些研究人员已经研究并基准调试工具[34]由于其在实践中的重要性然而，现有的研究主要集中在性能上（例如，运行时开销）而不是它们的有效性，这主要是由于缺乏可靠性基准测试套件。作为现有努力的补充，我们专注于故障诊断的有效性。具体来说，我们建议测量调试工具的可调试性，这是最近提出的用于提高系统可靠性的概念[35]。可观测性包括三个期望的特性（即，可见性、可重复性和可表达性）。直观地说，这个概念描述了工具允许开发人员进行的观察[35]，这对于调试至关重要。虽然可观测性的概念是众所周知的，但据我们所知，没有实用的方法来衡量它。在这项工作中，我们演示了如何使用现实的情况下，具体的指标来3. 存储故障在本节中，我们将介绍如何收集存储故障数据集（第3.1节）;数据集的总体特征（第3.2节）;以及如何导出存储故障数据集（第3.3节）。���������������������表1Bugzilla上的存储问题概述组计数平均值Avg. 评论/（%）已解决136（49.1%）146.9 8/3未解决141（50.9%）1444.2 5/2总数277 807.3 6/23.1. 方法为了了解存储堆栈的实际问题的特征，我们从Linux Bugzilla [72]收集了最终用户报告的故障问题。我们选择这个平台是因为它是普通用户向Linux内核社区报告遇到的故障的主要场所，并且报告的问题通常由内核开发人员通过详细的状态更新进行检查。由于该平台包含整个Linux内核的问题，超出了存储堆栈的范围，因此我们应用以下方法来细化数据集。首先，Bugzilla根据主要内核组件（例如，‘‘Process Management’’, ‘‘Networking’’), so we search“文件系统”、“IO/IO”、“存储器管理”、“驱动程序”）或通用组件（即，“其他”）;而且，问题的时间限于最近十年。接下来，为了确定一个可管理的和重要的子集进行研究，我们通过使用一组暗示严重故障后果的关键词（例如， 此外，对于保留软件RAID问题，但不包括GPU缓冲区损坏）。结果数据集总共包含277个问题，这代表了Linux最终用户遇到的严重存储故障的一个子集。请注意，此方法类似于关键字在以前的研究中搜索[53，73]。对有效性的威胁。本节中给出的表征结果应根据方法进行解释。特别是，数据集是通过关键关键词和手动工作进行细化的，这可能是不完整的。此外，只有一小部分Linux最终用户知道Linux Bugzilla，并且只有一小部分用户会报告问题。因此，很可能有更多的储存相关问题发生在野外，但在本研究中没有捕获。尽管如此，我们相信我们的努力是应对挑战的重要一步。3.2. 总体特征Bugzilla为报告的问题维护各种状态标签（例如，“新”、“已关闭”）。为简单起见，我们根据问题的状态标记将其分为两组：（1）已解决，包括状态为“已解决"或”已关闭"的问题我们在表1中总结了这两组。第二列显示每组中的问题数量（和百分比）。第三列显示问题的平均持续时间（天）。对于“已解决”组，持续时间是根据报告日期和最后一条注释的日期计算的;对于“未解决”组，持续时间是报告日期和撰写本文的时间之间的时间段最后一列显示了解决问题的平均评论数和参与者数我们提出多项意见如下：首先，这些问题平均需要几个月才能解决（例如，146.9天（表1中已解决组），诊断过程通常涉及多轮讨论和多人（例如，已解决组有8条评论和3名参与者），这从数量上表明了诊断存储故障的难度。其次，这些问题涉及存储软件堆栈中的所有主要组件。如图2，已解决组和未解决组均跨越D. Zhang和M. 郑BenchCouncil交易基准，标准和评估1（2021）1000064图二. 已解决（橙色）和未解决（绿色）问题在不同存储组件中的分布。图三. 存储组件中已解决问题的特征，包括平均持续时间（绿色条）、平均注释数（橙色线）和平均参与者数（灰色线）。在所研究的所有五个存储组件这意味着一个理想的调试工具应该提供全栈的可观测性。特别是，第三，对于已解决的问题，组件的平均调试时间始终很长。如图3所示，平均调试时间 这五个部分的时间超过100天。这意味着，由于 存储堆栈的复杂性，没有一个组件特别容易诊断，这再次表明捕获调试工具的全堆栈可观察性第四，在136个已解决的问题中，有37个（26.3%）涉及多个操作系统发行版或内核版本。问题的表现症状在不同的系统上往往不同，这表明软件环境（例如，内核、库）对于再现故障以进行诊断至关重要。第五，在136个已解决的问题中，只有5个（3.7%）是由硬件引起的。这意味着软件仍然是存储故障的主要来源，这与以前的研究一致[74]。此外，它表明，观察存储软件堆栈的行为是至关重要的故障诊断。3.3. ���������������������ℎ���为了识别最先进的调试工具的局限性以及进一步改进的机会，有必要拥有一组可重现的失败案例，以便我们可以应用目标工具并进行测量。为此，我们深入分析了一组存储故障问题，确定了触发问题所需的特定条件（例如，用户/工作负载操作、涉及的软件库、Linux内核版本和配置），并尝试在我们的服务器机器上重现案例。由于Linux内核的复杂性以及Linux最终用户系统设置的多样性，这是一个具有比如说，复制过程通常需要找到并（重新）编译具有非默认配置的Linux内核的特定版本，提取可能无法很好维护的特定软件包，导出工作负载程序以模拟各种用户的输入等。在撰写本文时，我们已经确定了61个具有相对完整信息的情况，可以复制在我们的环境中成功的三个案例。这种第一手经验进一步证实了故障诊断的挑战和对易于复制的基准测试套件的需求。为了确保案例能够可靠地复制，并使社区能够轻松共享复制的案例，我们将所有必需的软件程序和系统环境都在VM映像中。我们为每个成功复制的案例创建两个VM映像：第一个VM映像包含有缺陷的存储堆栈和用于复制案例的必要工作负载程序，库等;第二个VM映像包含修补的内核（即，存储堆栈中的错误已由相应的补丁修复）以用作验证的参考。此外，为了提高案例数量以及可重现案例的多样性，我们从Linux邮件列表中收集了更多与存储相关的错误案例[34]。Linux邮件列表中报告的案例通常是由开发人员在内部回归测试中直接发现的，因此它们可能不包含与Bugzilla最终用户报告的问题相同的信息（例如，没有用户经历后果、用户环境或解决状态）。这种开发人员发现的案例对于表征现实世界的故障影响或诊断难度（如第3.2节所述）的价值相对较低。然而，这些情况仍然是现实的，因为它们可能会影响早期发布的Linux发行版（即，在bug补丁之前）。换句话说，如果它们可以很容易地复制，那么它们就像Bugzilla问题一样有价值，可以用来衡量调试工具和其他可靠性实用程序。在撰写本文时，我们能够复制从Linux邮件列表中成功获得6个存储相关案例。我们还为这6个病例创建了相应的VM图像，以便于将来的可重复研究。根据9个可重复的病例（即，3个来自Bugzilla，6个来自 Linux邮件列表），我们创建了一个基准测试套件，虚拟机映像，它包括一组VM映像，其中包含所有必要的工作负载和系统环境/配置，以重现9个案例。我们在表2中总结了9例病例。所示表中，当前的Ext4原型覆盖了4种不同的文件系统，包括Ext4的2种情况（即，������������������������“1-EXT 4”、“2-EXT 4”），3例对于Btrfs文件系统（即，对于F2FS（即，“6-F2FS”）和1例GFS 2（即，“7-GFS'"）。此外，对于存储栈的低级块I/O层存在2种情况（即，‘‘8-BLK’’ and表2中的我们可以看到，关键函数的数量范围从1到7（在“6-F2FS”中根据文献中定义的漏洞模式，这9例病例的根本原因可分为不像其他类型的错误，有充分研究的模式来理解（例如，死锁、数据竞争），“语义"错误是实践中最难解决的问题之一，因为它们通常需要对系统设计逻辑有深入的理解 检测或诊断。换句话说，这些案件包括������������������������需要复杂的方法来有效诊断。“Bug大小”定义为Bug补丁中插入和删除代码（LoC）的行数之和，范围从6（在“2-EXT 4”中）到121（在“4-BTRFS”中），具体取决于案例的复杂性。最后一列显示了我们用来实现 错误触发工作负载。我们使用Bash、C或两者的组合来实现工作负载，这取决于用户报告（对于Bugzilla案例）或bug补丁（对于Linux邮件列表案例）中描述的输入特征。D. Zhang和M. 郑表5BenchCouncil交易基准，标准和评估1（2021）1000065可重复病例���������������������概述���。ext4_isize_set，cpu_to_le16，cpu_to_le32，文件系统文件系统文件系统层btrfs_record_snapshot_destroy，check_parent_dirs_for_sync，btrfs_release_pathbtrfs_log_inode，btrfs_record_unlink_dirf2fs_is_valid_blkaddr，zero_user_segment，，datalock_addr18.10层blk_mq_update_dispatch_busy，blk_mq_queue_request我们默认选择Ubuntu来重现这些案例，因为Ubuntu是许多Linux工具支持最好的操作系统发行版之一。 此外，由于许多 公用事业 和 包是 过时的或甚至在旧内核上不可用的情况下，我们将这些情况移植到最新的内核（即，v5.4.0）。对于5例（即，BTRFS’’, ‘‘6-F2FS’’, ‘‘7-GFS’’, ‘‘9-BLK’’), we are not able to reproducethe cases in the latest kernel because the affected kernel structureshave所以我们以相对较旧的版本再现它们（例如，v4.4.107、v4.15.0、v4.4.0），其中病例仍具有重现性。综上所述，目前的智能手机原型包括一套���������������������虚拟机映像再现9个真实的存储故障案例。这些可重复的案例，包括封装在虚拟机中的完整软件工作负载和环境，使我们能够方便地测量和评估工具的有效性。我们演示了������������������������中的两个代表性调试工具的上下文中，下一节（第4节）。4. 测量可观测性在本节中，我们将应用调试工具来学习FTrace和PANDA，这两种工具都是广泛用于调试（以及其他用途）的最先进的工具。���������������������我们发现，测量工具可以帮助测量工具与完全不同的设计原则。���此外，我们发现FTrace和PANDA都可以为大多数评估病例提供有用的信息。另一方面，当诊断一些棘手的病例时，两者都可能表现异常。 我们分别在第4.1节和第4.2 此外，我们发现，这两种工具都不能提供有关持久状态如何都变了我们将在4.3节讨论我们的扩展，以提高它们的低层可观测性。4.1. FTraceFTrace是Linux内核内部跟踪程序，自v2.6.27起已包含在主线Linux中。我们测量其主要特征的可观察性（即，核函数跟踪）。表3总结了应用FTrace诊断9例病例为非典型肺炎（在第一列中标记为从���第二列（“Still Reproducible”）显示在启用FTrace跟踪目标存储堆栈时是否仍然可以再现错误案例。我们可以看到，FTrace不影响任何情况下的再现性。换句话说，该工具是非侵入式的调试所有的情况下，在计算机上运行。第三列显示函数的总数（Func.）在每种情况下由FTrace跟踪，其中可能包括重复的条目如果在工作负载执行期间多次调用内核函数。我们运行FTrace三次并计算平均计数（例如，“1-EXT 4”的“12，506”）和方差范围（例如，“± 4.1%”）。我们可以看到，FTrace在大多数情况下都可以生成大量的函数，从类似地，第四列示出了在每种情况下跟踪的唯一函数的数量（即，不包括重复条目），其通常比所跟踪的函数的总数小得多（即，第三列）。这意味着相同的内核函数可能在所有故障情况下被调用多次。从调试第五栏（“关键功能”）。 Observed“）测量在每种情况下FTrace可以观察到多少个关键函数。如3.3节所述，临界函数是有问题的内核病例IDOS图像Linux内核存储组件批判功能错误类型错误大小简体中文1-EXT4Ubuntu20.04v5.4.0Ext4文件系统ext4_do_update_inode，ext4_clear_inode_state、ext4_update_inode_fsync_transs语义8C2-EXT4Ubuntu20.04v5.4.0Ext4parse_options语义6C Bash3-BTRFSUbuntu16.04v4.4.107BTRFS文件系统btrfs_ioctl_snap_destroy，btrfs_set_log_full_commit，btrfs_log_inode，语义71C4-BTRFSUbuntu16.04v4.4.107BTRFS测井尾孔语义121C5-BTRFSUbuntu20.04v5.4.0BTRFS文件系统btrfs_log_all_parents，btrfs_must_commit_transaction，语义13C6-F2FSUbuntu16.04v4.15.0版本F2FS文件系统f2fs_submit_page_bio，verify_block_addr，validate_checkpoint，存储器94C Bash7-GFSUbuntu16.04第4.4.0版GFS2gfs2_check_sb，fs_warn存储器18Bash8-黑色Ubuntu20.04v5.4.0块blkdev_fsync，sync_blkdev语义12CD. Zhang和M. 郑表6BenchCouncil交易基准，标准和评估1（2021）1000066对9例���������������������乳腺癌���病例的FTrace结果。案例ID仍然是关键功能的总数最短日志可再现？Func. 跟踪唯一函数观察距离大小（MB）1-EXT4是12，506（±4.1%）1，152（±0.7%）1/72-EXT4是54，796（±2.3%）1，436（±15.9%）0/1 2 9.17（±0.03）3-BTRFS是46，370（±5.6%）1，339（±1.5%）3/64-BTRFS是92，476（±5.5%）1，381（±1.0%）0/1 1 14.1（±0.43）5-BTRFS是30，528（±3.6%）1，419（±1.5%）3/46-F2FS是0 0 0/7- 07-GFS是0 0 0/2- 08-黑色是6，867（±2.7%）901（±4.3%）1/29-黑色是110，772，722（±6.4%）1，165（±0.8%）2/3导致存储故障的函数。 故障案例可能有多个关键功能作为根本原因，这取决于故障的复杂性。我们可以看到，虽然FTrace可以跟踪许多函数，但对于在“错误跟踪”中的情况，它可能无法有效地捕获关键函数。������������������������例如，在“1-EXT 4”中，有7个关键函数，但FTrace只能捕获其中一个（即，“1/7”）。同样，在其他四种情况下（即，“3-BTRFS”、“5-BTRFS”、“8-BLK”和“9-BLK”），只能观察到部分临界函数（即，就“2-EXT4”和“4-BTRFS”而言，这两种情况下的关键功能都不能被FTrace直接观察到（即，“0/1”在 两种情况下的第五列）。为了衡量这两种情况下被跟踪函数的相关性，我们进一步计算我们发现，尽管FTrace在“4-BTRFS”中错过了关键函数，但它实际上捕获了父函数（即，“最短距离”是“1”）。类似地，它捕获“2-EXT 4”中缺失的关键函数的父函数（即，“最短距离”是“2”）。这意味着FTrace可能仍然有助于诊断故障，即使它可能会错过一些特定的功能。为了理解为什么FTrace可能无法跟踪所有关键函数，以便在调试Windows Server 2008中的案例，我们将研究其内部������������������������关于FTrace我们发现FTrace依赖于一个预定义的列表来标识可跟踪的函数，该列表存储在目标系统的可跟踪函数列表中的可跟踪函数列表_可跟踪函数列表_可跟踪函数列表文件中���������������������������������������������������此外，默认列表可能包含我们评估的不同内核版本上的不同函数此列表从根本上限制了FTrace用于调试各种故障场景的可观察性，如第五列中不完整的关键函数（“关键函数”）所暴露的就“6-F2FS”和“7-GFS”而言，这两种情况在启用FTrace的情况下仍然是可再现的，但FTrace在任何一种情况下都不能提供太多帮助（即，“函数总数”中的“0”跟踪”）。这是因为这两种情况的表现都是内核恐慌。在这种情况下，FTrace无法正常工作。这个结果暴露了FTrace在调试内核中的存储堆栈时的一个基本限制：FTrace本身依赖于嵌入在内核中的探测器或跟踪点，因此它无法在严重的内核问题（例如，内核恐慌），更不用说在如此严重的情况下帮助诊断问题最后一列显示了FTrace在“日志记录”下生成的日志的大小。������������������������我们可以看到，在大多数情况下，FTrace占用的存储空间相对由于日志大小在很大程度上取决于工作负载操作的数量，因此低存储开销意味着包含在日志管理器中的工作负载对于触发7种情况是简洁有效的。������������������������另一方面，最后一种情况约7496 MB）。这是因为触发故障需要相对较重的工作负载。具体地说，工作负载包括通过dpkg包管理器从互联网上拉取和安装许多软件包，这涉及网络子系统和存储堆栈，并导致大量的内核函数被跟踪（即，，由于只有3关键函数导致了“9-BLK”情况下的故障，大量的跟踪函数可能会冲淡调试重点。 换句话说，可能需要更智能的方法来帮助从丰富的FTrace日志中获得见解以进行调试。4.2. 熊猫PANDA（Platform for Architecture-Neutral Dynamic Analysis）是一个开源的程序分析平台。通过利用虚拟化（即，QEMU [76]）和LLVM编译器基础设施[77]，PANDA可以帮助理解整个存储软件栈的行为。我们专注于测量其主要特征（即，记录重放） 以及4个相关插件（即，显示说明、污点分析、识别进程、进程-块关系），因为它们与诊断存储故障最相关由于PANDA记录了QEMU中托管的目标系统的完整状态以及快照中的所有非确定性事件，因此它可以通过设计实现全栈、所有指令的可观察性（即，所有执行的指令都可以通过重放来观察）。 因此，我们不计算用于测量FTrace的基于函数的指标（第4.1节）。相反，我们定性地测量目标特征是否适用于诊断故障。表4总结了应用PANDA诊断9例为慢性阻塞性肺疾病。与表3类似，第二列（“Still Reproducible”）显示使用PANDA时是否仍然可以重现错误案例。我们观察到PANDA对前8例病例没有引入任何干扰，与FTrace相似然而，PANDA在最后一个案例（“9-BLK”）中失败了。 具体来说，我们观察到，当应用PANDA诊断“9-BLK”案例时，来宾VM挂起。多种因素可能导致挂起。首先，如第4.1节所述，工作负载需要安装许多通过dpkg从Internet拉取的包。换句话说，这个工作负载涉及到网络子系统，并且往往会在内核中生成许多不确定的事件。 其次，基于QEMU的PANDA需要记录所有此类事件以确保成功重放，这在QEMU翻译客户机指令的关键路径中引起显著开销。结果，QEMU被PANDA的事件记录超载，并且不能按时完成访客指令的翻译。最终，客户内核（待诊断）挂在QEMU VM中。 这一结果表明，国家的最先进的记录重放机制可能不够轻量级诊断棘手的存储故障。对于其余8例，我们发现PANDA&重放功能和4个相关插件都可以正常工作（即，“”）以支持全栈可观察性。另一方面，全栈、所有指令的可观察性是以开销为代价的。最后一列显示，在大多数情况下，PANDA的快照和事件日志会产生数百MB的存储开销，这比FTrace在相同情况下生成的日志大几个数量级（表3）。请注意，在“6-F2FS”和“7-GFS”方面，FTrace由于到内核恐慌，PANDA仍然可以正常工作。这表明了基于VM的调试工具（如PANDA）的独特优势：通过隔离来宾VM中的目标存储软件堆栈，工具本身可以在目标系统出现严重问题时幸存下来，并仍然为诊断问题提供有效支持。D. Zhang和M. 郑BenchCouncil交易基准，标准和评估1（2021）10000672-EXT4是G G G G G671.97-GFS是G G G G G408.74-BTRFS是GG G G G811.7G G GGG G GG表4PANDA结果9���������������������月��� 例病例ID仍在重现-记录&插件日志大小ducible？重放显示污点识别进程块指令分析进程关系（MB）1-EXT4是G G G G G659.93-BTRFS是GG G G G380. 75-BTRFS是683.16- F2FS是G G G G G451.78-BLK是658.79-黑色否N/A N/A N/A N/A N/A N/A N/A图五. 8-BLK的增强QEMU日志示例见图4。 8-BLK的增强FTrace日志示例4.3. 增强低层可观测性通过对存储软件和存储设备之间通信的最低级别信息的实验，我们发现FTrace和PANDA都不能提供直接的可观察性，即，������������������������设备命令（例如，SCSI [70]）。这样的命令级信息在诊断存储故障中是有价值的，因为持久存储状态由设备命令直接改变。传统上，总线分析器[36，37]用于捕获此类命令级信息。但是，正如第2.2节所提到的，总线分析仪是基于硬件的工具，不像软件工具那样方便。在本小节中，我们引入软件扩展来捕获类似总线分析器的命令信息，并增强FTrace和PANDAFTrace扩展。避免引入不必要的复杂性针对内核中FTrace的探测机制，我们采用了一种间接的方式对FTrace进行了扩展。具体来说，我们使用定制的iSCSI驱动程序[78]来收集带有时间戳的设备命令，并根据时间戳将收集的设备命令与原始FTrace日志对齐。在这样做时，内核功能在相应的关键I/O路径下用低级设备命令进行了扩充。我们已经验证了这种扩展方法适用于所有情况下，FTrace可以正常工作，没有扩展。作为一个例子，图4显示了“8-BLK”情况下的扩展FTrace日志的简化版本。跟踪的内核函数使用基于时间戳的附加SCSI命令（粗体）进行了扩充。图4（a）示出了异常运行的扩充日志（即， bug被触发），在这里我们可以看到函数_最终生成了一个写入设备的命令���������������������这是有问题的，因为高电平同步功能（即，������������������同步操作_同步写入操作）应在设备命令级别生成低级同步操作（而不是简单的常规写入操作）。���图4（b）示出了相应的正 常 运 行 的 增 广 对 数 。 我 们 可 以 看 到 ， 一 个 额 外 的 同 步 命 令���������������������������������从本质上讲，我们的扩展结合了FTrace和传统的基于硬件的总线分析仪的功能[36，37]。通过以这种方式扩展FTrace日志的命令级信息，我们增强了FTrace的低级别的可观察性，而不使用特殊的硬件。PANDA扩展。如第4.2节所述，PANDA使用QEMU在来宾VM中托管整个存储软件堆栈，因此FTrace的iSCSI驱动程序解决方案不适用于PANDA。 相反，我们修改QEMU以捕获所有命令级信息，并利用QEMU具体地说，在QEMU中，客户操作系统内核通过在总线上发送命令描述符块（CDB）与SCSI设备进行通信。QEMU为每个SCSI命令维护 一 个 “struct SCSICommand” ， 其 中 包 含 一 个 16 字 节 的 缓 冲 区（“SCSICommand-> buf”），用于保存CDB。每个SCSI命令类型由CDB开头的操作码标识，CDB的大小由操作码决定例如，WRITE_10命令的CDB表示为D. Zhang和M. 郑BenchCouncil交易基准，标准和评估1（2021）1000068缓冲区的前10个字节为了简单起见，我们总是将16字节从缓冲区到命令日志，并使
我的内容管理
展开
