ZFS提供了大量强大的特性（快照、发送/接收、文件系统属性、克隆等）。强大的应用程序和实用程序已经建立在这些低级的ZFS原子之上，尽管并不总是那么容易。虽然每个单独的操作都是简单、直接和易于使用的，但是使用多个基本ZFS操作（销毁、快照等）的高效和更高级别的ZFS操作的正确和快速实现可能是困难或不可能的。为了说明这一点，让我们看几个例子。首先，让我们考虑一些现有的ZFS功能：ZFS destroy-r或递归destroy。递归销毁销毁文件系统及其所有子快照。递归销毁的实际实现需要三个步骤：收集文件系统的所有快照，销毁这些快照，然后销毁文件系统。这些步骤中的每一个都会调用内核，虽然每个步骤本身在原子上是一致的，但聚合递归销毁可能会在中间步骤中失败。例如，考虑这样一种情况：收集和销毁子快照成功，但另一个进程在发出实际的最终销毁操作之前创建目标文件系统的快照。在这种情况下，递归销毁将失败，因为该数据集的快照仍然存在。它不仅会失败，而且会返回一个既不是原始状态也不是期望状态的不一致状态，即使使用libzfs_core也不允许递归销毁的正确实现。创建新的ZFS业务怎么样？"zfs destroy-p'是zfs的一个计划添加，它会销毁文件系统及其所有快照，与"zfs destroy-r"相同。但是，如果要销毁的任何快照有克隆，"zfs destroy-p"首先升级最新的克隆。这个命令具有递归销毁所带来的所有一致性问题，因此正确地实现它需要对内核进行一些添加。然而，由于它是一个新特性，我们可能需要在原型制作时更改其语义。例如，虽然我们的原始设计销毁了所有快照并升级了它们的克隆（如果有的话），但是如果我们决定创建并升级任何没有预先存在的克隆的快照的克隆，会怎么样？这将需要对我们已经编写的任何现有特定于操作的内核代码进行重大修改和添加。多操作ZFS程序的性能也会受到影响，因为单独的操作被放在不同的事务组（txg）中，这些事务组对磁盘的提交间隔为秒。例如，"zfs destroy-R"删除了文件系统下的整个快照和克隆树，当快照和克隆的集合有效删除时（即，当它们自己的子树被删除时），它们必须迭代地提交给内核进行删除。对于快照和克隆的大型树，这意味着单个"zfs destroy-R"可以跨多个txg，并导致CLI响应速度不高或应用程序性能不佳。幸运的是，一个提议的OpenZFS项目ZFS Channel Programs（ZCP）采用了一种非常独特的方法来支持有效、正确和快速地实现复合ZFS操作。在较高的层次上，ZFS通道程序是发出给ZFS内核模块的基本ZFS操作的集合，这些操作将在单个原子可见的操作中运行。虽然高级编程接口仍然是个问号，但是传递给内核的对象将是一个控制语句和ZFS操作的树。例如，可以创建一个通道程序来递归销毁文件系统，方法是在iterate_over_snapshots控制语句中嵌套destroy_snapshot操作，然后执行destroy_文件系统操作。因为这些语句中的每一个都将在内核中进行评估，所以通道程序可以保证安全性，不受其他并发ZFS修改的干扰。从内核内部执行允许我们保证这些操作的原子可见性（改进的正确性），并允许它们在单个TXG中执行（改进的性能）。成功实施ZCP将：支持所有现有ZFS命令的同等或改进的功能和性能。只需编写一个新的频道程序，就可以方便地快速添加新的、有用的、功能更强大的命令。以前这需要对内核进行修改。由于ZCP层保证了每个通道程序的原子性，我们不再需要为每个新的IOCTL编写复杂且容易出错的新内核代码。提供与ZFS当前所做的相同的安全保证和权限保护，这样ZFS用户就不必担心写得不好的频道程序会破坏ZFS的状态。对频道程序进行额外的语法和结构检查将有助于支持这一点。一个完全向后兼容的ZCP内核接口。将频道节目作为nvlists来传递，应该是实现这一目标的主要途径。如果您认为ZFS频道节目和我一样令人兴奋和有趣，但希望更深入地了解技术细节，我建议您看看open上的项目提案-zfs.org网站：ZFS频道节目提案。由于这是一个提议的功能，我们鼓励您提出任何想法、意见，或者讨论developer@open-zfs.org邮件列表。