有没有办法在ZFS中创建母牛副本？

我正在尝试复制某些文件/目录，但据我所知的几种方式，它们似乎都不理想。

例如，btrfs可以使用cp --reflink=auto快速生成文件的文件副本。

我尝试过的

1. 符号链接：不好。重命名文件，链接断开。
2. 硬链接：更好，但仍然不好。更改一个文件会更改另一个文件，而我不一定要更改另一个文件。
3. 创建数据集的快照，然后克隆快照：可以，但是效果不佳。通常，我不是在寻找整个数据集的副本，也不是让副本像另一个数据集一样工作。然后在克隆/快照/原始文件之间存在父/子关系，据我所知，即使不是不可能打破的，这也很难。
4. 使用zfs send/receive和启用dedup，将数据集复制到新的数据集：这避免了使用克隆的父/子关系，但是仍然不必要地创建另一个数据集，并且仍然受累于必须100％读取文件和再次引用而不是写入的块。
5. 复制文件并让dedup发挥作用：这可行，但是速度很慢，因为必须100％读取文件，然后再次引用块而不是写入。

zfs的发送/接收以及物理复制或rsync的速度进一步恶化，因为大多数事物都被压缩存储，并且在读取过程中必须先解压缩，然后在dedup插入引用重复块之前进行压缩。

在我的所有研究中，我都无法找到与btrfs中--reflink的简单性相似的远程内容。

那么，有没有一种方法可以在ZFS中创建复本？还是“物理地”复制并让dedup做其工作是唯一的真实选择？

我认为，如您上面所述，选项3可能是您最好的选择。您想要的最大问题是ZFS实际上仅在数据集/快照级别处理此写时复制。

我强烈建议您避免使用dedup，除非您已验证它可以在您的实际环境中很好地工作。在迁移另一个用户或VM存储之前，我对dedup的工作很有经验，然后它又掉下了性能悬崖并引发了很多问题。仅仅因为它看起来可以与前十个用户一起很好地工作，所以当您添加第十一（或第十二，第十三，或其他）时，您的计算机可能会崩溃。如果您想走这条路，请绝对确保您拥有一个完全模仿您的生产环境的测试环境，并且该环境在该环境中运行良好。

返回选项3，您将需要设置一个特定的数据集来保存要以这种方式管理的每个文件系统树。设置好快照并进行初始填充后，拍摄快照（每个数据集一个快照，略有不同），然后升级为克隆。永远不要再触摸原始数据集。

是的，此解决方案有问题。我并不是说不是这样，但是鉴于ZFS的限制，它可能仍然是最好的。我确实找到了有效使用克隆的参考： http //thegreyblog.blogspot.com/2009/05/sparing-disk-space-with-zfs-clones.html

我对btrfs并不是很熟悉，但是如果它支持所需的选项，是否考虑过在该服务器上使用Linux和btrfs来设置单独的服务器以仅支持这些数据集？

选项5是最好的选择。

对于选项3中的父/子数据集，您可以升级克隆，它将不再是克隆数据集的子数据集。它仍然不会用完多余的块。 编辑：请注意，这只会反转父/子关系，不会破坏它。

关于被压缩/加密的事情以及放慢复制速度的事情，那完全是错误的。您的处理器要比块设备快得多（即使使用SSD）。仅举例来说，假设读取一个块需要10秒钟，而将其解压缩仅需要1秒钟，而解密则仅需要2秒钟。块1在10秒内被读取并发送到CPU。当磁盘开始读取块2时，CPU开始解压缩和解密。CPU将在3秒内完成其任务，然后在接下来的7秒内等待磁盘。同时，磁盘是否花费了完全相同的时间读取这两个块（20秒），而不管块是否被压缩。

同样，在写入时，只有第一个块被延迟。CPU压缩/加密块1并将其发送到磁盘。当磁盘正在写入块1时，CPU将开始压缩/加密后续块。CPU将检查块的速度比磁盘写入块的速度快得多，因此这不是问题。（是的，比这还复杂，但这是要点。）

抱歉，您对问题中的一个小问题的解释过于冗长，但我想消除这种误解。