OpenZFS项目正在增长！第二届OpenZFS开发者年会在不到两个月前结束，总的来说我认为它进行得非常顺利。大约有70名与会者，是去年的两倍，所作的会谈非常吸引人，也很有趣。我对illumos平台上的ZFS做了简短的介绍，并简要介绍了一些来自ZFS Linux背景下的主观观点。虽然有我演讲的视频记录，但我认为最好也以书面形式呈现出来，对于那些未能出席会议的人来说，这可能是一种更为平易近人的格式。所以这是。。。OpenZFS的历史正如大多数读者已经知道的，ZFS最初是在Sun Microsystems于2001年左右开始设计和开发的。它后来在2005年通过OpenSolaris作为开源发布。2010年，illumos作为OpenSolaris的分支诞生，2013年OpenZFS诞生。作为这种血统的结果，OpenZFS在illumos项目中真正感到"自在"；我的意思是，它与illumos操作系统和代码库作为一个整体进行了非常完美的集成。仅举几个明确的例子：作为根文件系统引导和运行ZFS非常容易（即使在磁盘上的特性发生变化时也是如此），因为它和引导加载程序都在同一存储库中活动和更改。illumos上的调试工具（如mdb）具有ZFS特定结构的知识，并具有ZFS特有的功能，以实现高效的调试和开发。但是，随着OpenZFS的发展，它在其他操作系统上的集成度也在不断提高。OpenZFS on illumos开发过程illumos上OpenZFS的开发模型遵循与所有其他illumos开发相同的约定。"倡导者"可以访问存储库，这些倡导者依靠社区（可能还有他们自己）来审查任何建议的更改，并确保更改是正确的和高质量的。在实践中，每个提议的变更都必须由主题专家（例如，对于OpenZFS，这通常是Matt Ahrens或George Wilson）审查和批准，然后才有律师提交变更。由于illumos项目没有任何特定版本，这意味着每次提交到存储库都必须是高质量的，因为每次提交实际上都是一个"发布"。没有合并已知有缺陷的代码的选项，目的是在"下一个版本"之前在后续提交中修复缺陷illumos Collaboration上的OpenZFS由于illumos上的OpenZFS是OpenZFS的"上游"平台，因此illumos开发人员和其他平台的开发人员之间必须有开放的交流和协作。当一个平台的更改合并到illumos中时，所有其他平台（理想情况下）都会将这些更改引入自己的OpenZFS版本中，这对双方都有利，原因有很多：在OpenZFS平台之间拉取更改时，在合并冲突上花费的时间更少。如果每个平台都在向illumos推送和从illumos拉取时处于活动状态，那么我们将使用尽可能接近相同的源代码。减少重复劳动。有很多次，我个人花了很多精力去调查或解决一个特定的问题，结果发现这个问题已经在另一个OpenZFS平台上解决了。如果每个平台都能更积极地保持彼此同步，这种情况就不太可能发生。更多不同的测试。如果所有平台都运行相同的代码，那么我们都会从每个平台带来的各种工作负载中获益；结果，我们都会测试彼此的代码。OpenZFS的新增功能。目前，大多数新的ZFS功能都是在illumos上首次开发的。因此，如果其他平台正在积极推动illumos的变化，这些新功能本来就是围绕着illumos开发的，并且包含了每个平台中最新的更改。这使得将新特性引入下游平台变得更加容易，从而允许所有OpenZFS用户尽快从新特性中获益。为了实现这一目标，需要简化和简化在illumos代码库上构建和测试OpenZFS更改的过程。这方面的工作正在进行中，我希望明年会有必要的改进，我们将能够为明年的开发者峰会唱出不同的曲调。illumos上的开发人员/调试工具在illumos上进行OpenZFS开发的好处之一是，我可以利用平台上可用的优秀开发工具。在过去的几年中，我花了很多时间在Linux内核中工作，我已经接受了几乎完全依赖源代码和堆栈跟踪来调试大多数生产和开发问题的训练。现在我已经跳槽到illumos，我可以亲眼看到dtrace、kmdb，尤其是mdb等工具所缺少的东西。在我从事illumos平台的短暂工作期间，我发现mdb很容易成为Linux上ZFS跳转的最佳部分之一。使用mdb的dcmds和管道可以轻松地完成某些在Linux上耗时数小时或难度极大的任务。例如，在Linux端口上处理ZFS时，我经常会对ARC kstat的发现感到困惑。为了尝试理解它，我想知道ARC中包含了什么，dbuf缓存中包含了什么；这最终导致在Linux端口上实现了"dbufs"proc处理程序。在illumos上，已经有一个mdb dcmd可以做到这一点：更好的是，如果需要详细程度，我可以打印每个缓冲区的完整内容：或者筛选出感兴趣的特定dbuf：但是，如果要过滤：：dbufs命令不支持的内容，该怎么办？这里有一个更通用的方法，使用：：grep:此外，使用kmem_flags=0x1获取详细对象分配位置的堆栈跟踪的功能非常有用。使用它，像：：refcount dcmd这样的东西不仅可以提供有关当前保留数的信息，而且还可以提供在执行挂起时接受保留的线程的完整内核堆栈跟踪。同样，：：whatis dcmd也使用此信息并将其显示给用户。想象一个例子，你有一个指向一个对象的"随机"指针（例如一个指向一个弧的指针），并且想知道这个对象来自何处。如果在illumos上使用kmem_flags=0x1，则如下所示：我可以继续谈论mdb允许的一些很酷的事情，但是这篇文章已经够长了，所以我在这里就不谈了。如果能看到一个mdb端口到Linux（或者甚至是一个支持OpenZFS的、功能更丰富的崩溃版本），那就太好了！