Zfs: 功能请求-在线拆分克隆

听起来zfs promote可能已经满足您的要求。

       zfs promote clone-filesystem

           Promotes a clone file system to no longer be dependent on its "ori
           gin"  snapshot.  This  makes it possible to destroy the file system
           that the clone was created from. The clone parent-child  dependency
           relationship  is reversed, so that the origin file system becomes a
           clone of the specified file system.

           The snapshot that was cloned, and any snapshots  previous  to  this
           snapshot,  are  now owned by the promoted clone. The space they use
           moves from the origin file system to the promoted clone, so  enough
           space  must  be  available  to  accommodate these snapshots. No new
           space is consumed by this operation, but the  space  accounting  is
           adjusted. The promoted clone must not have any conflicting snapshot
           names of its own. The rename subcommand can be used to  rename  any
           conflicting snapshots.

我当时在看zfs升级，但这似乎只是为了改变亲子关系...

我当时想的是两个文件系统彼此完全独立的最终状态。

一些用例可能是
克隆VM模板-具有被克隆以创建其他VM的基础映像，该映像又从模板中拆分出来，以便可以更新/销毁/重新创建模板
数据库克隆-为将要进行大量更改的dev克隆prod db，这又可能是测试克隆本身的基础，在这种情况下，最好将prod与prod分离，因为基本快照可能会变大比为开发人员拥有独立的文件系统

克隆original @ snapshot之后，您可以修改数据集和自由克隆，它们不会互相影响，除非它们共享两个磁盘上仍然通用的数据。

如果要销毁/重新创建模板（原始），只需销毁其上的所有快照（用作克隆源的快照除外），zfs重命名原始快照，zfs创建一个具有相同名称的新快照（origin属性）的克隆没有绑定到原始数​​据集的名称，因此您可以随意重命名两者。

唯一的缺点是，除非您愿意销毁克隆或升级克隆后，否则无法释放original @ snapshot （克隆的基础）中保存的所有_unique_数据。

最终，@ greg-hydrogen是否确定zfs promote满足您的需求？ 还是这里仍然有可能的功能要求。

对此发表评论，如果有一种功能可以将原始克隆关系转换为重复数据删除类型，那就太好了：删除使数据集不被随意破坏的逻辑链接，而仅保留一个仍然共享的副本数据。

@behlendorf ：几乎可以肯定它不能满足需要。
http://jrs-s.net/2017/03/15/zfs-clones-probably-not-what-you-really-want/
很好地解释了问题。

这是我在概念上要做的事情：

user @ backup ：

1. 生成基于日期的快照
2. 从备份发送它作为镜像进行测试

zfs snapshot backup/prod<strong i="11">@20170901</strong>
zfs send -R backup/prod<strong i="12">@20170901</strong> | ssh test zfs recv ... test/mirror

user @ test ：

1. 创建一个消毒镜子的地方
2. 消毒它
3. 快照
4. 克隆经过清理的版本以供使用
5. 用它

zfs clone test/mirror<strong i="23">@20170901</strong> test/sanitizing
sanitize sanitizing
zfs snapshot test/sanitizing<strong i="24">@sanitized</strong>
zfs clone test/sanitizing<strong i="25">@sanitized</strong> test/test
dirty test/test

user @ backup ：

1. 进一步利用了生产...
2. 创建更新的快照
3. 将增量更改从产品发送到测试
4. 删除以前的增量标记（在我的情况下，释放70GB）

dirty prod/prod
zfs snapshot backup/prod<strong i="35">@20170908</strong>
zfs send -I backup/prod<strong i="36">@20170901</strong> backup/prod<strong i="37">@20170908</strong> | ssh test zfs recv test/mirror
zfs destroy backup/prod<strong i="38">@20170901</strong>

user @ test ：

• 这是出现问题的地方。
• 伴随着一定程度的哄骗，就可以破坏消毒量。
• 但是，我剩下test/mirror@20170901 ，它是剩下的两件事的起源： test/mirror@20170908和test/test 。
• 如果愿意，我可以销毁更新的镜像（ test/mirror@20170908 ），但这对我没有任何好处（因为我的目标是使用该数据）。

为了使我取得进步，我实际上必须进行清理，停止正在使用测试的事物，完全破坏测试，将镜像克隆为测试，使用测试重新启动事物，然后我才能最终尝试破坏原始事物快照。 或者，我可以决定要通过，稍后在备份上触发新快照，然后将其增量发送出去，删除从未镜像过测试的快照，然后重试。

Fwiw，来品尝一下……：

zfs list -t all -o used,refer,name,origin -r test/mirror test/test
 USED   REFER  NAME                              ORIGIN
 161G   1.57M  test/mirror                       -
  65G   82.8G  test/mirror<strong i="54">@2017081710</strong>            -
    0   82.4G  test/mirror<strong i="55">@201709141737</strong>          -
3.25G   82.8G  test/test                         test/mirror<strong i="56">@2017081710</strong>

（数字确实是错误的，我实际上有1个卷，其中包含4个卷，因此是递归标志...）

现在，我了解到可以使用zfs send | zfs recv来打破依赖关系，并且可以用于一些小事情。 但是我池的这一部分大约是池中可用空间的两倍，而一半可能大于该空间，这意味着执行该操作是有问题的。 它也需要重新处理大量的字节。 我希望使用快照是希望能够从COW中受益，但是我要为COW付费，因为最终仍然需要为分支点两侧都将使用数据的分支点付费。

@behlendorf嗨，在这方面有什么进展吗？ 从原始文件系统中分离克隆对于虚拟机模板和/或大文件级别的还原确实非常@jsoref 。

@kpande ：目标是（在空间和数据传输中）为已更改的内容（COW）而不是整个数据集（每次执行此操作）支付费用。

如果我有一个10TB的移动数据集，并且要建立一个数据集的变体，那么可以复制10TB，应用变体并支付20TB（如果我有20TB）。 但是，如果我的版本确实与原来的10TB仅相差10MB，为什么我不能支付10TB + 10MB的费用呢？ -快照+克隆给了我。 在10TB移动到足以让我现在支付10TB（实时+ 10TB快照+ 10TB分散）和我的10MB变化移动直到它现在是自己的10TB（与实时和快照分开）之前。 在此期间，要“解决”我的30TB问题，我必须再花费10TB（= 40TB，通过zfs send + zfs recv）。 那不是理想的。 当然，它会“工作”，但既不“快速”，也不是节省空间。

编辑过的send / recv听起来很有趣（因为它或多或少与我的用例匹配）-但是虽然我可以在很多地方找到它，但是我找不到关于它实际上在编辑的有用的解释。

Fwiw，对于我们的系统，我进行了切换，以便在发送方进行清理（从隐私的角度来看也更好），这大部分使我们脱颖而出。

在某些情况下，数据变化没有“编辑”，并且系统具有zfs快照+ zfs发送的资源，但实际上并不想分配资源来托管另一个数据库来进行“突变”-不需要支付在主服务器和辅助服务器之间发送整个卷的费用（即，它宁愿将增量快照发送到已具有先前快照的系统）。

是的，我知道我可以使用dedup。 我们要为cpus / ram付出代价，因此将恒定的cpu + ram专用于快速完成罕见的任务（刷新突变克隆）感觉就像是一种较差的权衡（我宁愿付出更多的磁盘空间）。

@kpande此链接非常清楚地显示了当前克隆的问题。 毕竟，如果克隆与基本快照的差异很大，则两者之间的永久父子关系将引起混乱。 拆分克隆将清楚地表明它们之间的差异太大，不再被认为是捆绑在一起的。

但是，让我做一个更实际的例子。

假设kvm/vmimages是多个虚拟磁盘映像的数据存储容器，每天拍摄快照。 我知道默认答案是“为每个磁盘使用数据集”，但是libvirt池不能很好地发挥作用。 因此，我们有如下内容：

kvm/vmimages
kvm/vmimages<strong i="11">@snap1</strong>
kvm/vmimages<strong i="12">@snap2</strong>
kvm/vmimages<strong i="13">@snap3</strong>

在某些时候，虚拟磁盘发生了一些问题（例如，严重的来宾文件系统损坏），但是与此同时，其他用户正在将新的重要数据主动存储在其他磁盘上。 您基本上有一些不同的要求：a）恢复到昨天的旧数据，而不是损坏的数据； b）保留任何快照中都找不到的任何上载的新数据，以及c）使服务中断降至最低。

克隆是一种可能的解决方案：您可以将kvm/vmimages@snap3克隆为kvm/restored以立即为受影响的VM恢复服务。 因此，您现在拥有：

kvm/vmimages
kvm/vmimages<strong i="20">@snap1</strong>
kvm/vmimages<strong i="21">@snap2</strong>
kvm/vmimages<strong i="22">@snap3</strong>
kvm/restored   # it is a clone of snap3
kvm/restored<strong i="23">@snap1</strong>
...

受影响的VM从kvm/restored ，而所有其他VM仍在kvm/vmimages 。 此时，您将从kvm/restored删除所有多余的磁盘，并从kvm/vmimages删除损坏的原始磁盘。 一切似乎都很好，直到您意识到旧的损坏的磁盘映像仍在使用实际的磁盘空间，并且由于旧的不可删除的kvm/vmimages@snap3导致kvm/restored任何覆盖都会消耗额外的空间。 您不能在不删除克隆的情况下删除此旧快照，也不能简单地升级kvm/restored并删除kvm/vmimages因为它不是唯一的真正“权威”数据源（即：真实数据是存储在两个数据集中）。

从其来源拆分克隆将完全解决上述问题。 我不清楚在这种情况下，编辑过的send / recv会如何帮助。

@kpande首先，感谢您分享您的观点和解决方案（这很有趣！）。 我完全同意，仔细且非常具体的来宾配置（和主机数据集树）可以避免上述问题。

也就是说，libvirt（及其存储池的实现）在这种方法中不能很好地发挥作用，尤其是在使用Windows虚拟机管理混合环境时。 更甚者，这仅仅是一个例子。 可拆分克隆将非常有用，例如，当用于创建“金主/基本映像”时，可随意实例化该副本以创建“真实”虚拟机。

在当前情况下，这样做将使您在分配的空间中负担沉重，因为您将永远无法删除原始的，可能已过时的快照。 令我惊讶的是，作为ZFS的CoW文件系统，这应该是一个相对简单的操作：删除原始快照时，“简单地”将任何未引用的块标记为空闲，并删除父/子关系。 换句话说，让克隆成为一个真实的文件系统，与任何源快照无关。

请注意，我在引号中使用了“简单”的世界：虽然这确实是一个简单的逻辑操作，但是我不确定它是否/如何映射到基础zfs文件系统。

@kpande好吧，很公平-如果存在真正的技术问题，我必须接受。 但这不同于说明特定用例无效的情况。

如果zfs开发人员对此观点（即：不可能从其原始父快照中拆分克隆而不涉及“神话般的” BPR）达成共识，那么我认为可以关闭该FR。

谢谢。

需要此功能时+1。 是的，可以使用send / recv，但是这将需要停机，无论使用该数据集从旧的（克隆）切换到新的数据集都需要停机。

我遇到过使用LXD进行复制（克隆）容器的情况，但是这会导致我单独管理的快照出现问题。

@kpande ：再次，我的用例有整个数据集是一个数据库，以及数据库的几个变体。

从我所看到的情况来看，overlayfs看起来在文件系统中的w / zfs效果不佳（根据您的笔记，w / zvols和ext4 / xfs看起来很高兴）。 听起来像这种方法将涵盖大多数情况，在这种情况下，欢迎使用解释如何使用ext4 / xfs设置overlayfs的文档。

也就是说，我们中的一些人不仅将zfs用于卷管理，还用于acl / allow / snapshot行为/浏览，并且希望能够使用w / zfs的overlayfs而不是ext4 / xfs，所以如果不是不可能，有没有bug？ 如果有的话，最好是从此处开始突出显示，如果没有，那么，如果您赞同overlayfs方法，也许可以提出来（如果您坚持，我可能会写出来，但是我不会）一无所知，这似乎是本文中的一项关键技术）。

从我所看到的情况来看，overlayfs看起来在文件系统中的w / zfs效果不佳（根据您的笔记，w / zvols和ext4 / xfs看起来很高兴）。 听起来像这种方法将涵盖大多数情况，在这种情况下，欢迎使用解释如何使用ext4 / xfs设置overlayfs的文档。

该overlayfs方法将一个极其重要的，而不是普通的工作，用例：克隆虚拟图像从另一个（或一个“金主”模板）开始。 在这种情况下，分割克隆将是避免原始/克隆图像发散时浪费空间的关键。

@ ptx0仅在来宾操作系统支持overlayfs （因此不支持Windows VM）并且最终用户（即我们的客户）愿意显着更改其VM映像设置/安装时才有效。 附带说明一下，虽然我完全理解并接受-该PR在技术上是封闭的（例如：如果涉及BPR），但是将合法的用户案例标记为“无效”是非常令人沮丧的。 如果不是您的用例，那很好。 但是，请不要以为没有人为此功能提供有效的用例。

Windows不需要overlayfs，它具有内置的文件夹重定向和漫游配置文件。

文件夹重定向自NT以来就一直存在，但由于软件存在（出于晦涩的原因）不能正确处理重定向的文件夹，并且在遇到重定向的Desktop或Documents时仅会失败，因此不能始终使它工作。 除此之外，Windows安装的克隆完全独立于自身，与Windows Update的起源产生了巨大且相当快的差异-Windows Update提供了便利-让不同的用户登录和注销只会加快安装速度。