构建一个稳定的、现代化的文件系统是一项不小的壮举。我与ZFS合作得越多，我对它的正确性和可延展性的印象就越深刻。它的发展是为了弥补缺点和适应潜在的技术变化。尽管ZFS的基础经受住了生产使用的考验，但ZFS偶尔仍显示出它的不成熟，这一点并不奇怪。甚至在2008年推出ZFS存储设备之前，ZFS就被大量使用并讨论了Solaris和OpenSolaris社区，这是经常受到赞扬和批评的话题。一个常见的抱怨是写繁重的工作负载会消耗大量的系统内存。。。然后，由于ZFS尽职尽责地将新数据存放到通常不太好用的存储器（OpenSolaris用户通常只有一个主轴），因此导致系统无法使用。对于生成新数据的能力远远超过持久存储的吞吐量的工作负载，ZFS显然需要施加一些限制。ZFS应该对专用于"脏"（修改）数据的系统内存量有有效的限制。应限制事务组，以防止高延迟IO和管理操作。从较高的层次上讲，ZFS事务组只是写操作（事务）的集合，在任何给定的时间都可以有三个事务组处于活动状态；要获得更彻底的处理，请查看去年的ZFS knowledge一期。写入节流阀1.0（2008）提出的解决方案要求对系统有直观的了解。在最高级别，不要让事务组无限期地增长。当一个事务达到指定的大小时，淘客家园，ZFS将创建一个新的事务组；如果已经存在三个事务组，云快卖，它将阻塞等待同步事务组完成。限制每个事务组的大小可以带来许多好处。ZFS将不再消耗大量的系统内存（平息了用户群体的强烈抗议）。在事务组边界处执行的管理操作将更具响应性。而且同步的、对延迟敏感的操作不必面对来自同步事务组的大量写入。那么交易组应该有多大？该解决方案包括一个用于写出事务组的目标持续时间（5秒）。每个事务组的大小将基于该时间目标和推断的写入带宽。持续时间乘以带宽等于目标大小。推断出的带宽将在每个事务组之后重新计算。当达到事务组的大小限制时，新的写入操作将等待下一个事务组打开。如果还没有三个事务组处于活动状态，那么这几乎是即时的，或者可能会导致严重的延迟。为了改善这一点，写节流阀将为所有新写操作插入10毫秒的延迟，一旦消耗了7/8的大小。查看git提交中的血腥细节。评论ZF在最初的努力中认真地写下了一些可以理解的关键问题。在某种程度上，它成功了。虽然当时缺乏严格的ZFS性能测试，但这反映在初始写节流阀的明显缺陷上。一个简单的逻辑错误持续了两个月，导致所有写操作延迟10毫秒，而不仅仅是事务组达到其目标容量的7/8后执行的写入操作——是的，这是微不足道的，但也会让人精疲力尽。对写节流阀的计算导致值变化很快；最终在迟滞处增加了一个快速的工作。退一步，神奇的常数引起了人们的关注。为什么事务组应该持续5秒？是的，它们应该足够大，以便在事务组中分摊元数据更新，软件企业条件，并且它们不应该太大，企业管理的软件，以至于导致管理上的无响应。对于ZFS存储设备，我们尝试使用较低的值，以消除周期性的写操作——这种效果我们称之为"纠察围栏"，因为它出现在IO可视化界面中。更引人注目的是，7/8的截止时间是从哪里来的，还是10毫秒的延迟呢？即使计算的吞吐量非常精确，该算法也会导致ZFS不必要地延迟写操作。乍一看，这个方案并没有致命的缺陷，但肯定是武断的，与实际结果脱节，几乎不可能在复杂的系统上进行推理。问题写节流显示了比广泛观察到的栅栏更严重的问题。虽然ZFS试图建立一个稳定的写吞吐量估计值，但实际计算出的数字会剧烈波动。因此，ZFS会有不同程度的过油门和欠油门。它通常会加上10毫秒的延迟，但这种延迟仅仅是为了比硬限制更软的着陆。一旦达到第一级的限制，延迟仍然会造成严重的限制。下图显示了来自生产系统的两个IO延迟的功率的频率（计数）和总贡献（时间）。延迟频率清楚地显示出三种模式的分布：以软件速度（远低于1ms）进行的写入、因写入限制而延迟的写入（数十毫秒）以及根据事务组大小（数百毫秒到数秒）而增加的写入。每个延迟桶的总累积时间突出显示了异常值的巨大影响。花费一秒钟或更长时间的110个操作比剩余16000+个操作的时间对总运行时间的贡献更大。新焦点第一次尝试写节流阀解决了一个关键的需求，但指导思想是修补漏洞，而不是了解根本问题。ZFS将数据移动到持久存储的速率将因各种原因而变化：同步操作将消耗带宽；并非所有写入操作都以相同的方式影响存储--分散写入高碎片区域的速度可能比顺序写入慢。不管实际的、即时的吞吐量容量如何，ZFS都需要将有效成本（以写延迟为单位）传递给客户机。writethrottle1.0将此成本分为三部分：在事务组的早期写入不支付任何费用，在事务组中延迟写入，每个事务组只需支付10ms的开销，以及在结束时提取剩余账单的部分。如果传入数据的速率小于持久存储的吞吐量容量，云服务器和普通服务器，则客户机不应收取任何费用—不应插入延迟。按照这个标准，写节流也失败了，在不需要额外收费的情况下会延迟10毫秒。理想情况下，ZFS应该以一种优化的方式来限制写操作，以最小化和一致的延迟。当我们开发了一种新的写节流阀时，我们的目标是降低写入延迟的差异，以及对持久性存储的稳定和一致（而不是突发性）写入。在我的下一篇文章中，我将描述Matt Ahrens和我为OpenZFS设计的解决方案。