"zfs销毁"有多快？这是一个很难回答的问题，因为我们可以销毁许多不同类型的数据集（快照、文件系统、卷、克隆），而且这些数据集中的数据可能非常不同（许多小文件、大顺序访问的文件、大的稀疏文件）。在本文中，我将研究一个对Delphix很重要的特定案例：删除虚拟数据库（VDB）。VDB是克隆，包含用于存储数据库的文件。大部分空间都在几个大文件中，通常recordsize=8k，块会随机更新。这种访问模式在zvols（用于为iSCSI和FC目标提供服务）、基于文件的虚拟磁盘（vmdk文件）和（最重要的是对于Delphix）数据库来说很常见。为了回收空间，我们必须释放不再需要的单个块。对于文件系统或zvol，我们必须遍历它的元数据树（间接块和dnode），以找到所有需要释放的块。对于recordsize=8k的大文件，从磁盘读取的每个间接块产生大约1MB的空间，这些空间将被释放。由于文件是随机更新的，间接块在磁盘上不会是连续的，因此这些读取将大致随机偏移到磁盘。使用一个7200RPM的磁盘，它可以执行大约100个随机IOPS，我们将能够在不到3个小时内回收1TB的数据。删除文件系统或克隆有两个主要步骤。我们必须将其从名称空间中删除（删除到其他相关快照的链接，例如克隆源），然后按照上面所述回收可用空间。直到最近，我们还是按相反的顺序执行这些步骤：首先通过删除每个文件来回收未使用的空间，然后从名称空间中删除文件系统。在DelphixOS 2.7.0中，Chris Siden引入了"async_destroy"功能，该功能于2012年5月集成到Illumos中。启用此功能后，我们将以更好的顺序执行这些操作：首先从命名空间中删除文件系统或克隆，然后在后台回收未使用的空间。为此，我们需要改变遍历元数据的方式。旧算法找到每个修改过的文件，然后将其删除。新算法是一种更为字面量的树遍历，它遍历自克隆创建以来修改的块。我想测量修改算法对性能的影响，特别是销毁VDB（数据库的克隆）。我发现新代码比旧代码快得多——超过100倍！这让我很惊讶，所以我研究了每个代码路径在磁盘上实际读取的块。我发现旧代码实际上是在读取每个修改过的文件的每个间接块，即使该文件只有几个块被修改。新代码只读取自克隆创建以来修改的块。如果没有async_destroy功能，销毁克隆的速度与销毁原始文件系统一样慢（对于引用1TB，但新数据可以忽略不计的克隆，因此回收的空间可以忽略不计）一样慢。使用async_destroy，最坏的情况是克隆中修改的每个间接块中只有一个修改过的数据块，因此从磁盘读取的每个数据块产生大约8K的空间，因此我们可以回收大约800K/秒。这可能仍然很慢，但至少与回收的空间量（即克隆中修改的空间量）成比例。我还发现，在DelphixOS2.7.0-2.7.2中，在遍历元数据树时，我们一次只向磁盘发出一个读I/o。在delphixos2.7.3中，我让遍历代码并发地发出多个I/o，当池由多个物理磁盘组成时，这大大提高了性能。我们在DelphixOS和Illumos中显著提高了删除克隆的性能。它现在在后台工作，所需时间与回收的空间量成正比。此代码可供任何开源ZFS实现利用（FreeBSD、Linux、Nexenta等）。