TxFS：崩溃一致性ACID事务的文件系统

ACM Transactions on Storage，Vol.号152、第9条。出版日期：2019年5月TxFS：利用文件系统崩溃一致性提供ACID事务Yige Hu和Zhiting Zhu，德克萨斯大学奥斯汀分校9伊恩·尼尔，密歇根大学KAIST，Youngjin KwonTIANYU CHENG，德克萨斯大学奥斯汀VIJAY CHIDAMBARAM，德克萨斯大学奥斯汀分校和VMware研究院Emmett WITCHEL，德克萨斯大学奥斯汀分校我们介绍TxFS，一个事务文件系统，建立在文件系统的原子更新机制，虽然之前的工作已经探索了许多事务文件系统，但TxFS具有一组独特的属性：简单的API，跨不同硬件的可移植性，高性能，低复杂性（通过构建在文件系统日志上）和完整的ACID事务。我们端口SQLite，OpenLDAP和Git使用TxFS和实验表明，TxFS提供强大的崩溃一致性，同时提供相等或更好的性能。CCS概念：·软件及其工程→软件组织和属性;上下文软件域;操作系统;文件系统管理;软件功能属性;核心技术;一致性; ·通用和可靠性→核心计算工具和技术;性能;其他关键词和短语：操作系统，文件系统，崩溃一致性，ACID事务ACM参考格式：Yige Hu，Zhiting Zhu，Ian Neal，Youngjin Kwon，Tanyu Cheng，Vijay Chidambaram，and EmmettWitchel. 2019. TxFS：利用文件系统崩溃一致性提供ACID事务。 ACM Trans. 存储15，2，第9条（2019年5月），20页。https://doi.org/10.1145/33181591介绍现代应用程序将持久状态存储在多个文件中[24]，有时将它们的状态拆分到嵌入式数据库、键值存储和文件系统中[31]。这些应用程序需要确保其数据在崩溃时不会损坏或丢失。不幸的是，现有的崩溃一致性技术导致复杂的协议和微妙的错误[24]。伊恩·尼尔和Youngjin Kwon在UT工作。这项工作得到了NSF（CNS-1618563，CCF-1333594）以及VMware、Facebook和Google的慷慨捐赠的部分支持作者Hu，Z.Zhu，V.Chidambaram，E.Witchel，University of Texas at Austin，Computer Science Depart-ment，2317Speedway，2.302，Austin，Texas 78712; email：{yige，zhitingz，vijay，witchel}@cs.utexas.edu; T.程，320南首都公路得克萨斯州;电子邮件：tianyu.cheng@ utexas.edu;我。Neal，密歇根大学计算机科学与工程系，Bob和BettyBeyster Building，2260 Hayward Street Ann Arbor，MI 48109-2121;电子邮件：ian.gl. gmail.com;Y. Kwon，KAIST，291 Daehak-ro，Yuseong-gu，Daejeon 34141，Republic of Korea; email：yjkwon@kaist.ac.kr.允许免费制作本作品的全部或部分的数字或硬拷贝，以供个人或课堂使用，前提是制作或分发副本的目的不是为了盈利或商业利益，并且副本的第一页上有本声明必须尊重作者以外的其他人拥有的本作品组件的版权。允许使用学分进行摘要以其他方式复制、重新发布、在服务器上发布或重新分发到列表中，需要事先获得特定许可和/或付费。从permissions@acm.org请求权限。© 2019版权归所有者/作者所有。授权给ACM的出版权。1553-3077/2019/05-ART9 $15.00https://doi.org/10.1145/3318159ACM Transactions on Storage，Vol.号152、第9条。出版日期：2019年5月第九章：Y. Hu等人××事务提供了一种直观的方式来原子地更新持久状态[6]。不幸的是，构建事务性系统是复杂且容易出错的。在本文中，我们将介绍一种构建事务文件系统的新方法我们利用了操作系统中一个成熟的、经过良好测试的功能：文件系统日志，它用于确保对文件系统的内部状态进行原子更新我们使用日志事务提供的原子性和持久性，并利用它来构建用户空间ACID事务。我们的方法极大地减少了构建事务文件系统所涉及的开发工作量和复杂性我们将介绍TxFS，这是一个建立在ext4文件系统日志机制之上的事务文件系统。我们设计TxFS是为了实现和使用。TxFS有一组独特的属性：它有一个小的实现（5，200日元）通过建立在期刊上（例如，TxFS具有TxOS事务操作系统的25%的带宽）;它提供了高性能，不同于在用户空间数据库上构建事务文件系统的各种解决方案[5，19，21，37];它有一个简单的API（只需将代码包装在fs_tx_begin（）和fs_tx_commit（）中）与Valor [32]或TxF [28]等解决方案相比，这些解决方案需要每个事务多个系统调用，并且可能需要开发人员了解日志记录等实现细节;它提供所有ACID保证，不像CFS[17]和AdvFS [36]这样的解决方案，它们只提供一些保证;它提供文件级而不是块级的事务，不像Isotope [30]，使几个优化更容易实现;最后，TxFS不依赖于底层存储的特定属性，不像MARS [3]和TxFlash [26]等解决方案。在文件系统日志上构建TxFS的优势在于，通过将每个TxFS事务完全放置在单个文件系统日志事务中，TxFS事务可以获得原子性、一致性和持久性，该事务以原子方式应用于文件系统。使用经过良好测试的日志代码来获取ACID可以降低TxFS的实现复杂性，同时将事务的最大大小限制为日志的大小构建TxFS的主要挑战是提供隔离。TxFS事务的隔离要求在事务提交之前，正在进行的TxFS事务对其他进程不可见。在高级别上，TxFS通过为所有读取或写入的数据制作私有副本并在提交期间更新全局数据来实现隔离然而，这种方法的简单实现将是非常低效的：全局数据结构（如位图）将导致每个事务的冲突，导致高中止率和过多的事务重试。TxFS通过收集对全局结构的逻辑更新并在提交时应用更新来TxFS还包括许多其他优化，比如即时冲突检测，这些优化是针对ext4中文件系统数据结构的当前实现而定制的我们发现，事务框架允许我们轻松地实现一些文件系统优化。例如，我们早期工作的核心技术之一，将有序性与持久性分离[2]，在TxFS中很容易实现类似地，我们发现TxFS事务允许我们识别和消除冗余的应用程序IO，其中临时文件或日志用于原子地更新文件：当序列简单地包含在事务中（并且没有任何其他更改）时，TxFS原子地更新文件（保持功能），同时消除对日志或临时文件的IO（假设临时文件和日志在事务内被删除因此，TxFS提高了性能，同时提供了更好的崩溃一致性语义：崩溃不会留下需要清理的难看的临时文件或日志为了展示TxFS事务的强大功能和易用性，我们修改了SQLite、OpenLDAP和Git以合并TxFS事务。 我们表明，当使用TxFS事务时，SQLite在TPC-C基准测试中的性能提高了1。6，模仿Android Mail的微基准测试获得2. 3更好的吞吐量。通过移植OpenLDAPLDIF的TxFS版本提供了与Berkeley DB（BDB）后端相同的保证，TxFS：利用文件系统崩溃一致性提供ACID事务第九章：ACM Transactions on Storage，Vol.号152、第9条。出版日期：2019年5月×性能提升至12. 五、使用TxFS事务极大地简化了Git的代码，同时提供了崩溃一致性而没有性能开销。因此，TxFS事务提供了崩溃一致性，降低了复杂性，并提高了性能。我们的文章做出了以下贡献。我们将介绍TxFS的设计和实现，TxFS是一种通过利用文件系统日志构建的现代应用程序的事务文件系统（第3节）。我们已在https://github.com/ut-osa/txfs上公开提供TxFS。我们证明了现有文件系统我们展示了实际应用程序可以很容易地修改为使用TxFS，从而获得更好的崩溃语义和显着提高的性能（第5节）。2背景和动机我们首先描述了当前应用程序使用的协议，以崩溃一致的方式更新状态然后，我们提出了一个研究不同的应用程序和他们所面临的挑战，在maintaining崩溃的一致性在不同的抽象存储的持久状态我们描述了由事务实现的文件系统优化，最后总结了为什么我们认为应该重新审视事务文件系统2.1应用程序今天如何更新状态假设现在的应用程序不能访问事务，那么它们如何一致地将状态更新到多个存储位置呢？即使系统崩溃或电源故障，应用程序也需要在不同文件中跨状态维护不变量（例如，图像文件应该与图片库中的应用程序通过使用复杂且容易出错的adhoc协议来实现这一点[24]。在本节中，我们将展示实现看似简单的协议来持续更新存储是多么困难有许多细节经常被忽视，比如目录内容的持久性这些协议复杂、容易出错且效率低下。对于当前的存储技术，这些协议必须牺牲性能才能正确，因为没有有效的方法来订购存储更新。目前，应用程序使用fsync（）系统调用来命令对存储的更新;由于fsync（）强制数据的持久性，因此fsync（）调用的延迟从几毫秒到几秒不等因此，应用程序不会在更新协议中的所有必要位置调用fsync（），导致严重的数据丢失和损坏错误[24]。我们现在描述应用程序用来一致地更新稳定存储的两种常用技术。图1显示了这些协议。原子能 协议（a）显示了如何通过原子重命名来更新文件。原子重命名方法被Emacs和Vim等编辑器以及需要以原子方式更新点配置文件的GNOME应用程序广泛使用应用程序将新数据写入临时文件，使用fsync（）调用将其持久化，使用另一个fsync（）调用更新父目录，然后将临时文件重命名为原始文件，从而有效地使原始文件的目录条目指向临时文件。原始文件的旧内容将被取消链接并删除。最后，为了确保临时文件已正确解除链接，应用程序在父目录上调用fsync（）测井 协议（b）展示了另一种流行的原子更新技术，日志记录[8]（写前日志记录或撤销日志记录）。日志文件将写入新内容，并且日志文件和父目录（带有指向日志文件的新指针）都将持久化。应用程序然后···第九章：Y. Hu等人ACM Transactions on Storage，Vol.号152、第9条。出版日期：2019年5月图1.一、应用程序使用不同的协议对持久性数据进行一致的更新更新原始文件并保存原始文件;父目录在此步骤中不会更改最后，日志被取消链接，父目录被持久化。当应用程序跨多个文件存储状态时，情况变得更加复杂。Pro- tocol（c）说明了Android Mail应用程序如何添加带附件的新电子邮件。附件存储在文件系统中，而电子邮件消息（以及元数据）存储在数据库中（对于SQLite，数据库也驻留在文件系统中由于数据库具有指向附件的指针文件名），则必须首先持久化附件。持久化附件需要两次fsync（）调用（对文件及其包含目录）[1，24]。SQLite然后，它遵循类似于方案（b）的方案。在任何呈现的协议中删除fsync（）调用将导致数据丢失或损坏。例如，在Protocol（b）中，如果父目录没有通过fsync（）调用持久化，则可能发生以下情况：应用程序写入日志文件，然后开始将原始文件重新写入。此时系统崩溃重新启动时，日志文件不存在，因为指向日志文件的目录项没有持久化。因此，应用程序文件已被不可逆地部分编辑，并且无法恢复到一致的版本。许多应用程序开发人员避免fsync（）调用，因为这会导致性能下降，从而导致严重的错误，导致数据丢失。用于稳定存储的安全更新协议复杂且性能低（例如，Android Mail使用六个fsync（）调用来持久化一封带有附件的电子邮件对事务的系统支持将为这些应用程序提供高性能双日志。SQLite使用写前日志来提供原子更新。为了实现写前日志，SQLite需要两个同步写操作：一个将数据写入日志，另一个将数据就地写入文件。1SQLite运行在ext4这样的文件系统之上，1使用批处理检查点，第二次写入可以在后台完成TxFS：利用文件系统崩溃一致性提供ACID事务第九章：ACM Transactions on Storage，Vol.号152、第9条。出版日期：2019年5月还实现了元数据更新的预写日志记录。因此，文件系统会记录对SQLite预写日志的更新（元数据处于有序模式，数据和元数据均处于日志模式）。这会导致对存储的额外写入和缓存刷新。这就是所谓的双重日志问题：维护应用程序级日志会对文件系统的日志造成额外的写入。如果事务是在文件系统内部实现的，那么只需要两个同步写操作。2.2应用案例研究我们提出了四个应用程序的例子，努力获得崩溃的一致性使用原语今天。一些应用程序跨文件系统、键值存储和嵌入式数据库（如SQLite）存储数据虽然所有这些数据最终都驻留在文件系统中，但它们的API和性能约束是不同的，并且跨这些系统一致地更新状态是复杂且容易出错的。Android Mail. Android的默认邮件应用程序使用SQLite嵌入式数据库存储邮件消息[ 33 ]。邮件附件作为文件单独存储，数据库存储指向该文件的用户要求文件和数据库都被原子地更新; SQLite只确保数据库被正确地更新。例如，崩溃可能会使数据库保持一致，但会有一个指向丢失的附件文件的悬空指针。邮件应用程序通过首先持久化附件和包含附件的目录文件（通过fsync（）），然后持久化数据库事务来处理这个问题。跨数据库和文件系统的事务只有一个提交点，从而简化了语义，并可能简化恢复。单个事务还可以消除附件的fsync（），这可以提高性能。移动照片共享应用程序。 Android Gallery将照片（包括缩略图）的元数据存储在SQLite数据库中，同时将文件本身直接存储在文件系统中。因此，崩溃可能会使数据库更新文件信息和缩略图（因此看起来好像文件在那里），但当访问文件时，用户会得到错误。苹果工作和生活。 对Appl e的家庭使用应用程序的存储器的分析[ 10 ]发现，应用程序使用文件系统、键值存储和SQLite的组合来存储数据。iTunes使用SQLite来存储元数据，类似于Android Mail应用程序。当你通过iTunes下载一首新歌时，声音文件会被传输，数据库也会随着歌曲的音乐而更新。 个人的Pages应用程序使用SQLite和键值的组合来检索用户首选项和其他元数据（两个SQLite数据库和128个.plist键值存储文件）。与Android Mail类似，Apple使用fsync（）来正确订购更新浏览器。 Mozilla Firefox将用户数据存储在多个SQLite数据库中。例如，附加组件、Cookie和下载历史记录都存储在各自的SQLite数据库中。由于下载文件和其他文件存储在文件系统中，因此崩溃可能会使数据库带有指向丢失文件的悬空同步服务。Dropbox、Seafile和Box允许用户在桌面和移动系统以及云端之间保持文件同步。这两个服务的桌面客户端都使用SQLite来存储文件元数据，例如文件上次修改和同步的时间Box的桌面客户端除了使用SQLite和文件系统之外，还使用了键值存储当一个文件被添加到一个同步的文件夹中时，所有这些存储抽象都需要自动更新版本控制系统。 Git和Mercurial是广泛使用的版本控制系统。git commit命令要求两个文件系统操作是原子的：文件追加（logs/HEAD）和文件重命名（到锁文件）。未能实现 原 子 性 会 导 致 数 据 丢 失 和 存 储 库 损 坏 [24] 。 Mercurial 使 用 不 同 文 件 的 组 合（journal、filelog、manifest）第九章：Y. Hu等人ACM Transactions on Storage，Vol.号152、第9条。出版日期：2019年5月以持续更新状态。 Mercurial的commit需要一长串的文件系统操作，包括文件创建、追加和重命名，否则存储库就会损坏[ 24 ]。对于这些应用程序，事务支持将直接导致更容易理解和更有效的习惯用法。用户级程序很难使用POSIX文件系统接口提供崩溃一致事务性文件系统接口还将支持高性能习惯用法，如编辑器将更新分组到事务中，而不是当前使用的生成提交的临时文件副本的低效过程通过重命名。请注意，像对临时文件进行原子重命名这样的应用程序技术确实可以实现崩溃控制;但是，崩溃可能会导致需要清理的临时文件崩溃后，应用程序运行恢复过程并返回到一致状态。通常，“恢复过程“迫使人类用户查找并手动删除陈旧文件。transansactional文件系统不为这些应用程序提供新的崩溃一致性保证;相反，它们消除了恢复和清理的负担，简化了应用程序并消除了错误[24]。2.3优化交易事务性文件系统接口支持许多有趣的文件系统优化。我们现在描述其中的一些删除临时持久文件。许多应用程序，如Vim、Emacs、Git和LevelDB，都提供了合理的崩溃语义（即，用户看到旧版本或更新后的新版本），这是通过制作文件的临时副本、编辑它、然后在用户更新数据时将它应用程序可以通过避免文件复制并简单地将其写入包含在事务中来更有效地对于大文件，性能差异可能很大。此外，事务向用户保证，在崩溃的情况下，文件系统不会被临时文件弄得一团糟集团承诺事务在内存中缓冲与文件系统相关的更新，这些更新可以同时发送到存储设备。批处理更新通常会提高系统效率，例如，能够更好地分配文件系统数据结构和更好的设备级调度。没有用户提供的事务边界，文件系统为所有更新提供统一的、尽力而为的持久性消除事务中的冗余IO工作负载通常包含冗余;例如，文件通常在同一偏移量处更新多次，或者文件被创建、写入、读取和取消链接。事务边界允许文件系统消除一些冗余工作，因为整个事务在提交时对文件系统可见，从而实现全局优化。跨事务整合IO 事务经常更新先前事务写入的数据。当工作负载预期其事务中的数据将很快被另一个事务更新使用特殊标志提交事务允许系统延迟事务提交，预计数据将被覆盖，然后可以持久化一次而不是两次。注意，以这种方式整合IO不同于消除事务中的冗余IO;这种优化跨多个事务操作。优化多个事务，特别是来自不同应用程序的事务，最好由操作系统完成，而不是由单个应用程序完成。这种非工作保存策略类似于预期磁盘调度器[14]。将订购与耐久性分开。在结束事务时，程序员可以指定事务是否应该持久提交。如果是，则调用将阻塞，直到TxFS：利用文件系统崩溃一致性提供ACID事务第九章：ACM Transactions on Storage，Vol.号152、第9条。出版日期：2019年5月事务已写入持久日志。如果应用程序提交了非持久事务A，然后启动了非持久事务B，则A的顺序在B之前，但两者都不是持久事务。后续交易（例如，C），可以指定它和所有以前的交易应该是持久的。通过这种方式，我们可以使用transactions来获得将同步拆分为有序同步（osync）和持久性同步（dsync）的大部分好处[2]。总之，我们认为应该重新审视事务文件系统，原因有两个。首先，应用程序通常将持久状态存储在多个文件中并跨不同的存储系统（例如数据库和键值存储）存储，并且使用诸如原子重命名之类的技术来维护该状态的崩溃一致性会导致复杂性和错误。第二，使用事务API使文件系统能够提供许多优化，这些优化在非事务文件系统中很难3TXFS的设计与实现我们现在介绍TxFS的设计和实现TxFS避免了早期trans-functional文件系统的缺陷（第6节）：它有一个简单的API;提供完整的ACID保证;不依赖于特定的硬件;并利用文件系统日志和内核实现的方式来实现小的实现（15，200MB）。3.1API一个简单的API是TxFS的关键目标之一因此，TxFS只为开发人员提供了三个系统调用：fs_tx_begin（），它开始一个事务;fs_tx_commit（），它结束一个事务并尝试提交它;以及fs_tx_abort（），它丢弃当前事务中包含的所有文件系统更新在提交时，应用程序级事务中的所有文件系统更新都以原子方式持久化-在崩溃后，用户可以看到所有事务更新，也可以什么都看不到这个API大大简化了应用程序代码，并提供了干净的崩溃语义，因为临时文件或部分写入的日志在崩溃后不需要清理系统调用fs_tx_commit（）返回一个值，指示事务是否成功提交，或者如果失败，则返回失败的原因。一个事务可能会因为三个原因而失败：与另一个并发事务发生冲突，没有用于事务的日志空间，或者文件系统没有足够的资源来完成事务（例如，没有空格或索引节点）。根据错误代码，应用程序可以选择重试事务。嵌套的TxFS事务被扁平化为单个事务，作为一个单元成功或失败平面嵌套是事务系统中的常见选择[25，32]。用户可以使用fs_tx_begin（）和fs_tx_commit（）包围任何与文件系统相关的系统调用序列，系统将在单个事务中执行这些系统调用。该接口易于程序员使用，并且可以简单地将文件系统事务增量部署到现有应用程序中。相反，一些事务文件系统（例如，WindowsTxF为每个事务分配一个句柄Valor将内核日志上的操作公开给用户级代码。TxFS仅隔离文件系统更新。应用程序仍然负责同步对其自己的用户级数据结构的访问。事务性文件系统并不打算成为应用程序3.2原子性和耐久性大多数现代Linux文件系统都有一个内部机制来原子地更新存储上的多个块，例如日志[35]或写时复制[11]。这些机制对于第九章：Y. Hu等人ACM Transactions on Storage，Vol.号152、第9条。出版日期：2019年5月保持文件系统崩溃一致性，因此具有经过良好测试的成熟实现。TxFS利用这些机制来获得ACID的三个属性：原子性、一致性和持久性。这是允许TxFS具有小型实现的关键见解TxFS建立在ext4文件系统的日志之上日志保证每个日志事务以原子方式应用于文件系统我们可以使用不同的机制，例如写时复制，它在btrfs和F2FS中提供原子更新TxFS可以构建在任何具有原子更新机制的文件系统对于每个TxFS事务，TxFS维护一个私有jbd2事务，并在提交时将私有事务合并到全局jbd2事务中。虽然默认情况下全局jbd2事务仅包含元数据，但TxFS还向事务添加数据块以确保原子更新。如果添加到私有jbd2事务的块碰巧也被前一个全局jbd2事务提交，那么TxFS会创建一个影子块。当一个正在运行的事务和一个正在提交的事务共享一个块时，Ext4也会创建一个影子块为了减少写入日志的数据量，TxFS采用选择性数据日志[2]。选择性数据日志记录仅记录已经分配的数据块（即，正在被更新的数据块）并且避免日志记录新分配的数据块（因为它可以直接写入它们选择性数据日志记录提供了与完整数据日志记录相同的保证，而成本仅为后者的一小部分TxFS确保整个事务可以合并到单个日志事务中;否则，将向用户返回错误。只要将TxFS事务添加到单个日志事务，日志将确保它以原子方式应用于文件系统在将用户的事务合并3.3隔离和冲突检测尽管ext4日志提供了原子性和持久性，但它并不提供隔离。在Linux内核中为文件系统数据结构添加隔离是一项挑战，因为内核中的大量函数在不使用公共接口的情况下修改文件系统数据结构。在TxFS中，我们为每个数据结构定制了隔离方法，以简化实现。为了提供隔离，TxFS必须确保在事务内部执行的所有操作在提交时间之前对其他事务或系统的其余部分不可见。TxFS使用不同技术的组合来实现可重复读取的隔离级别[7]拆分文件系统功能。write（）和open（）等系统调用执行文件系统函数，这些函数通常会导致分配文件系统资源，如数据块和inode。TxFS将这些函数分为两部分：一部分进行文件系统分配，另一部分对内存结构进行操作。执行文件系统分配的部分被移动到提交点。另一部分作为系统调用的一部分执行，内存中的更改对事务保持私有。事务专用副本。 TxFS为事务期间修改的所有内核数据结构创建事务私有副本。事务内部与文件系统相关的系统调用对这些私有副本进行操作，从而允许事务读取它们自己的写操作。在中止的情况下，这些私有副本将被丢弃;在提交的情况下，这些私有副本将以原子方式小心地应用于文件系统的全局状态在事务期间，文件系统操作被重定向到数据结构的本地内存版本例如，由事务更新的dentry被修改为指向维护具有本地修改页面的本地基数树的本地inodeTxFS：利用文件系统崩溃一致性提供ACID事务第九章：ACM Transactions on Storage，Vol.号152、第9条。出版日期：2019年5月两阶段提交。TxFS事务使用两阶段提交协议提交。TxFS首先使用总顺序获得所有相关文件系统数据结构上的锁。以下顺序可以防止死锁：inode互斥锁、页锁、inode缓冲区头锁、全局inode_hash_lock、全局inode_sb_list_lock、inode锁和dentry锁。Linux内核根据索引节点的指针地址来命令获取索引节点互斥锁;我们在TxFS中采用这种锁定规则类似地，按页地址的顺序获取页锁获取目录数据块和inode元数据的缓冲区锁按inode编号排序。在获得锁之后，检查所有分配决策以查看它们是否会成功;例如，如果事务创建了inode，则TxFS检查是否有足够的空闲inode。接下来，TxFS检查日志，以确保全局jbd2事务中有足够的空间允许合并事务。最后，TxFS检查与其他事务的冲突（如下所述）。如果这些检查中的任何一个失败，那么所有的锁都将被释放，提交将返回一个错误给用户否则，将更新内存中的数据结构，执行所有文件系统分配，并将私有jbd2事务与全局jbd2事务合并。此时，事务被提交，锁被释放，更改被持久化到一种碰撞一致的方式。冲突检测。冲突检测是提供隔离的关键部分。由于分配结构（如位图）直到提交时才被修改，因此它们不能同时被多个事务修改，也不会引起冲突;因此，TxFS避免了涉及全局分配结构的错误冲突检测具有挑战性，因为文件系统数据结构在没有标准接口的情况下在整个Linux内核中被修改TxFS利用文件系统数据结构的实现方式来有效地检测冲突。页面冲突检测 struct页面数据结构保存缓存文件的数据。TxFS在这个结构中添加了两个字段：write_flag和reader_count。write_flag指示是否存在已写入此页的另一事务。reader_count字段指示已读取此页的其他事务的数量。非事务性线程永远不会看到事务中未提交的数据，因此总是可以安全地读取数据。TxFS对页面进行即时冲突检测，因为TxFS插入的页面只有一个读写接口。在页面读或写时遵循以下规则(1) 当一个事务读取一个页面时，它将reader_count加1。如果页面设置了write_flag，那么它一定是由当前正在执行的事务写入的（现在是冲突），因此该事务中止。(2) 如果事务尝试写入设置了write_flag或如果reader_count大于零，则它中止;否则，它设置write_flag。(3) 如果非事务性线程尝试用reader_count或write_flag置位，那么它将进入睡眠状态，直到事务提交或中止。(4) 当事务提交或中止时，write_flag被重置，reader_count被递减。以这种方式中止事务可能会导致活锁，但我们没有发现这是我们的基准测试的问题，并且可以很容易地更改策略以解决冲突，从而有利于最旧的事务（不活锁）。TxFS有利于事务吞吐量，但为了在事务和非事务线程之间实现更大的公平性，TxFS可以允许非事务线程通过中止由其操作冲突的所有事务来继续[25]。Dentry和Inode的冲突检测 除了页面之外，TxFS还必须检测其他两种数据结构上的冲突：dentry（目录条目）和inode。不幸的是，与佩奇不同，第九章：Y. Hu等人ACM Transactions on Storage，Vol.号152、第9条。出版日期：2019年5月图二、TxFS依赖于ext4在提交时，本地操作将成为全局的和持久的。inode和dentry不具有标准接口，并且在整个内核代码中被修改。因此，TxFS对inode和dentry使用惰性冲突检测，在提交时检测冲突在提交时，TxFS需要检测数据结构的全局副本自复制到本地事务后是否发生了对每个修改的数据结构进行逐字节比较会显著增加提交延迟;相反，TxFS利用inodeTxFS类似地将新的d_ctime字段添加到dentry数据结构中以跟踪其最后修改时间，并在dentry更改时更新d_ctime在一个目录中创建不同的命名条目不会产生冲突，因为名称是在提交时检查通过利用i_ctime和d_ctime，TxFS能够对这些结构执行冲突检测，而无需从根本上更改Linux内核。摘要 图2显示了TxFS如何使用ext4的日志来原子地更新事务中的操作，并维护本地状态以提供隔离保证。 TxFS 事 务 中 的 文 件 操 作 被 重 定 向 到 事 务 只 有 在 TxFS 事 务 通 过 调 用fs_tx_commit（）完成其提交后，其修改才会全局可见。3.4执行我们修改了Linux 3.18版本和ext4文件系统。该实现总共需要5,200行代码，其中1,300行用于TxFS内部簿记，1,600行用于VFS层，900行用于日志（JBD 2）层，1,200行用于ext4，200行用于内存管理（所有测量均使用SLOCCount [4]）。除了ext4和jbd2扩展之外，所有其他代码都可以重用，以便将来将TxFS移植到其他文件系统，例如NTFS3.5限制TxFS有两个主要限制。首先，TxFS事务的最大大小被限制为日志大小的四分之一（ext4允许的最大日志事务大小）。我们注意到，日志可以配置为所需的大小今天，几千兆字节的期刊很其次，尽管并行事务可以在ACID保证下进行，但是每个事务TxFS：利用文件系统崩溃一致性提供ACID事务第九章：ACM Transactions on Storage，Vol.号152、第9条。出版日期：2019年5月×表1.TxFS事务加速的编程习惯用法工作量FSTX创建/取消链接/同步37.35s0.28秒（133×）测井5.09s4.23s（1.20×）订购工作2.86它/秒3.96it/s（1.38×）性能以秒和每秒迭代次数（it/s）为单位进行度量括号中报告了交易案例的加速只能包含来自单个进程的操作跨多个流程的事务是未来的工作。4使用TXFS我们现在探索一些编程习惯，其中事务API可以提高性能，因为事务为文件系统提供了一系列可以作为一个组进行优化的操作（第2节）。全事务优化可以显著提高性能，因为文件系统可以消除临时持久写入（例如创建、使用和删除日志文件）。在某些情况下，我们证明了以前通过新接口（如osync[2]）获得的好处可以通过事务轻松获得4.1消除文件创建当应用程序创建临时文件时，同步它，使用它，然后取消链接（例如，日志记录如图1b）所示，将整个序列封装在事务中允许文件系统优化文件创建和所有写入，同时保持崩溃一致性。create/unlink/sync工作负载产生六个线程（每个核心一个），每个线程重复创建一个文件，取消链接，并同步父目录。表1显示，将操作放在事务中可以将性能提高133，因为事务完全消除了工作负载虽然这个测试是一个极端的情况，但我们接下来将研究如何使用事务将日志记录协议自动转换为更有效的更新协议。4.2消除日志IO图1（b）显示了现代应用程序用来实现崩溃一致性的日志习惯用法将整个协议封装在事务中允许文件系统透明地将该协议优化为更有效的直接修改。在TxFS事务期间，所有同步系列调用都是功能nop。由于日志文件是在事务中创建和删除的，因此不需要在事务提交时使其持久消除日志文件的持久性大大减少了用户数据量，但也减少了文件系统元数据（例如，块和inode位图）。表1显示了一个微基准测试的执行时间，该测试在单个TxFS事务中写入并同步日志和包含整个协议的版本将日志记录协议封装在事务中可以将性能提高20%，并将执行的IO量减少一半，因为日志文件永远不会持久化。重写代码可将性能提高55%（3.28秒，表中未在这种情况下，要从事务中获得最大的性能，需要重写代码以消除事务造成的冗余工作但是，即使没有程序员重写，仅添加两行代码来将协议包装在事务中，也可以实现完全重写的47%的使用TxFS优化SQLiteL日志。SQLite的3个端口结果。 只是把第九章：Y. Hu等人ACM Transactions on Storage，Vol.号152、第9条。出版日期：2019年5月表2. 下表总结了用于评估TxFS的微观和宏观基准测试，以及每个实验中获得的性能改进（相对于有序日志模式下的ext4）实验TxFS效益性能改进单线程SQLite更快的IO路径，更少的同步1.3倍TPC-C更快的IO路径，更少的同步1.6倍安卓邮件交叉抽象2.3倍OpenLDAP崩溃一致性、可扩展性12.5×Git崩溃一致性1.0×使用事务记录活动可将更新性能提高14%。 修改代码以消除事务冗余的日志记录工作，将更新的性能提高到31%，部分原因是系统调用的数量减少了2。5倍。4.3区分有序性和耐久性表1显示了一个工作负载的吞吐量，该工作负载创建三个10MB的文件，然后更新一个单独的40MB文件中的10MB用户希望先创建文件，然后更新数据文件。这种类型的排序约束经常出现在像Git这样的系统中，这些系统创建日志文件和其他保存中间状态的文件第一个版本使用fsync（）对操作进行排序，而第二个版本使用允许前三个文件创建操作以任何顺序执行的事务，但它们都在最终数据更新事务之后被序列化（使用fs_tx_begin（）和fs_tx_commit（）的标志）。事务性方法的吞吐量高出38%，因为排序约束与持久性约束是分离的首先区分排序和持久性的工作建议添加不同的风格同步系统调用[2]，但TxFS可以通过事务实现相同的结果5评价我们在各种微基准测试和实际工作负载上评估TxFS的性能和持久性保证微基准测试有助于指出TxFS如何实现特定的设计目标，而更大的基准测试验证了事务提供了更强的崩溃语义，并以最小的移植工作提高了各种大型应用程序的性能试验台。我们的实验测试台由一台配备4核Intel Xeon E3-1220 CPU和32 GB DDR3 RAM的机器和一台配备6核Intel Xeon E5-2620 CPU和8 GB DDR3 RAM的机器所有实验均在Ubuntu 16.04 LTS（Linux内核3.18.22）上进行内核安装在三星850（512GB）SSD上，所有实验都在三星850（250GB）SSD上完成。实验SSD以低利用率（约20%）运行，以防止磨损均衡固件的混淆因素。表2提供了用于评价TxFS的不同实验的总结以及在每个实验中获得的在Git实验中，TxFS提供了强大的崩溃一致性保证，而不会降低性能。请注意，如果没有明确指出，我们所有的基线都运行在ext4上，并具有默认的日志模式，即有序日志模式。5.1崩溃一致性TxFS的ACID事务在系统崩溃后应该是可恢复的。为了验证这一关键的正确性，我们启动一个虚拟机并运行一个创建多种类型事务的脚本TxFS：利用文件系统崩溃一致性提供ACID事务第九章：ACM Transactions on Storage，Vol.号152、第9条。出版日期：2019年5月表3.该表比较了SQLite在一个事务中执行1.5M 1KB操作和10K操作的每秒操作数（越大越好）和总IO量使用不同的日志模式（包括TxFS）性能（kOps/s）IO（GB）同步/发送Journal方式插入更新插入更新插入更新回滚（默认）53.928.01.93.9410截形53.5（0.99×）28.9（1.03×）1.93.9410Wal39.8（0.74×）34.6（1.23×）3.9