我一直在探索ZFS，试图理解性能病态，并提高性能。一个特别的兴趣点是ZFS写节流阀，下载返利，ZFS使用这种机制来避免用修改过的数据填充所有的系统内存。我很想写下我们在Delphix在这方面取得的进展，但是如果不了解ZFS是如何批处理数据的，很难理解。不幸的是，这个解释根本找不到。早在2001年，我还没有开始从事DTrace的工作，我正和ZFS的作者Matt和Jeff讨论加入他们的事宜。他们只做了几个月；我很幸运地和他们参加了一次会议，讨论了关于交易组的想法。事务组是ZFS如何批处理要写入磁盘的数据块（"事务"的"组"）。Jeff站在白板前画出了事务组的状态进程，全民淘客，从打开、接受新事务到停止、允许事务完成，再到同步、将数据写入磁盘。据我所知，那是第一次画这幅画，也是最后一次。如果您搜索关于ZFS事务组的信息，您会发现提到了这些状态……其他的就不多了。usr/src/uts/common/fs/zfs/txg.c中的标题注释并不是特别有用：/**池范围事务组。 */我开始写一篇关于ZFS事务组的适当描述。我先把它贴在这里，我会把它作为提交给illumos的。非常感谢Matt Ahrens，George Wilson和Max Brunning的反馈。ZFS事务组顾名思义，ZFS事务组是作用于持久状态的事务组。ZFS在这些事务组的粒度上声明一致性。每个连续事务组（txg）都被分配一个64位的连续标识符。同步组有三种状态：打开或关闭事务。在任何给定的时间，可能存在与每个状态相关联的活动txg；每个活动txg可能正在处理，或者被阻塞，返利软件，等待进入下一个状态。可能有多达三个活动的txg，什么叫物联网，并且始终有一个txg处于打开状态（尽管它可能被阻塞，等待进入静止状态）。广义地说，事务（改变内存结构的操作）在打开状态下被接受到txg中，并在txg处于打开或静止状态时完成。累积的更改将以同步状态写入磁盘。正常开放当新的txg激活时，它首先进入打开状态。新的事务（内存结构的更新）被分配给当前打开的txg。总是有一个txg处于open状态，以便ZFS可以接受新的更改（尽管txg可能会拒绝新的更改，如果它达到了某个限制）。ZFS由于各种原因将opentxg提前到下一个状态，例如它达到了时间或大小阈值，或者执行了必须在同步状态下完成的管理操作。安静txg退出打开状态后，进入静止状态。静止状态旨在在接受处于打开状态的新事务和在同步状态下将它们写入稳定存储器之间提供一个缓冲区。在静止时，事务可以继续其操作，而不会延迟其他任何状态。通常，txg处于静止状态的时间非常短暂，因为操作受到软件延迟的限制，而不是较慢的I/O延迟。所有事务完成后，txg准备进入下一个状态。同步在同步状态下，在打开期间建立的内存中状态和（在较小程度上）静止状态被写入稳定存储器。写出修改过的数据的过程可以反过来修改更多的数据。例如，当我们编写新的块时，我们需要为它们分配空间；这些分配修改元数据（空间映射）…这些元数据本身必须写入稳定的存储。在同步状态期间，ZFS迭代，写出数据，直到它收敛并且所有内存中的更改都被写出。第一个这样的过程是最大的，因为它包含所有修改过的用户数据（与文件系统元数据相反）。随后的过程通常要写的数据要少得多，因为它们完全由文件系统元数据组成。为了确保收敛，在经过一定数量的传递之后，ZFS开始覆盖先前在同步状态下分配（随后释放）的稳定存储上的位置。ZFS通常分配新的块来优化大的、连续的写操作。但是，为了使同步状态收敛，它必须完成一个过程，其中没有分配新的块，因为每次分配都需要修改持久元数据。此外，为了加快收敛，在指定的传递次数之后，ZFS还延迟free，并停止压缩。除了写出用户数据，我们还必须在同步上下文期间执行synctasks。synctask是一些管理活动的工作机制，例如创建和销毁快照或数据集。请注意，当一个synctask被启动时，它将进入opentxg，然后ZFS将该txg尽快推送到同步状态，以减少管理活动的延迟。为了完成同步状态，高防云服务器，ZFS写出一个新的uberblock，它是组成存储在ZFS池中的所有状态的块树的根。最后，如果有一个静止的txg在等待，我们发出信号，它现在可以转换到同步状态。还有什么？请让我知道，如果你有关于如何改进上述描述的建议。关于实现、事务、DMU，以及一般的ZFS，还有更多的细节需要编写。我要注意的一件事是马特最近跟我提到，如果他从头开始，他可能会消除安静状态。直到我研究了这个子系统，我才完全理解。通常事务需要很短的时间才能"完成"，这是由CPU延迟来衡量的，而不是I/O延迟。如果将静止阶段合并到同步阶段，设计将稍微简单一些，并且它将消除大部分空闲的中间阶段，其中大量脏数据可以相对空闲地存放在内存中。接下来，我将介绍ZFS write throttle，它是各种中断，以及我们如何修复它的想法。