Ubuntu 20.04的zsys将ZFS快照添加到包管理中

去年10月，一个实验性的ZFS安装程序出现在Eoan Ermine中，这是2019年的第二个临时Ubuntu版本。下个月，焦点Fossa(Ubuntu的下一个LTS(长期支持)版本)将会放弃，它保留了ZFS安装程序，同时使用羽翼未丰的zsys包为Ubuntu的系统管理增加了几个新功能。

Phoronix本周末报道说，zsys现在正在软件包管理操作之前拍摄快照，所以我们决定安装最新的Ubuntu 20.04每日版本，看看新功能是如何工作的。

Focus的安装和其他任何Ubuntu版本差不多，但是它保留了19.10&39；的ZFS安装程序--它仍然隐藏在高级功能后面，仍然被贴上试验性的标签。选择ZFS安装后，您可以对生成的分区布局表示同意-一个主分区用于UEFI引导，三个逻辑分区用于交换、引导ZFS池和根ZFS池。几分钟后，您就可以安装Ubuntu了。

安装Fossa之后，我们做的第一件事就是验证已安装的zsys版本。APT管理快照是最近在0.4.1中添加的，我们已经学会了不要想当然地认为Linux发行版的测试版或测试版前每日版本上安装的东西是理所当然的。实际上，默认情况下已经安装了Zsys，并且版本是0.4.1。

在新安装的系统上还没有任何快照，所以我们快速安装了gimp。之后，我们看到zsys已经在rpool上存在的每个数据集中拍摄了快照。在安装新软件包之前拍摄快照意味着，如果出现问题，我们可以很容易地将系统恢复到安装新软件包之前的状态。将系统划分为这么多不同的数据集意味着，反过来，我们只能回滚系统中受软件包管理器影响的那些部分-例如，我们可以回滚软件包，而不会影响用户主目录中的数据。

在安装GIMP并看到新的快照可用后，我们尝试安装第二个软件包。一个APT安装PV之后，我们再次检查快照。尽管我们仍然找到了在安装GIMP之前拍摄的快照，但是没有新的快照可以回滚我们的PV安装。在又进行了几次没有新快照的实验性安装和删除之后，我们开始grep/etc目录，以找出原因。

在apt.conf.d中，我们找到一个名为90_zsys_system_autosnapshot的配置文件，该文件将预安装挂钩添加到dpkg。在对软件包系统进行任何更改之前，此预安装挂钩调用zsys-system-autosnapshot。我们不确定为什么没有获得任何新的快照，所以我们尝试直接运行zsys-system-autosnapshot-仍然没有新的快照。

然后，当我们查看zsys-system-autosnapshot本身时，没有拍摄新快照的原因是显而易见的。最短时间间隔内置于该脚本中，这样，如果距离上次拍摄快照的时间不到20分钟，则它将退出而不执行任何操作。

我们对这一最小间隔功能持相当怀疑的态度。一方面，一旦您积累了几千个快照，您就可以开始看到文件系统性能问题。另一方面，我们预计会有大量有问题的软件包安装没有以这种方式包含在快照中。

我们应该注意到，zsys还远远没有完成。该工具承诺提供各种附加功能，而且它已经很有用了--但它仍然缺少普通用户需要看到的许多改进之处。

我们可以看到，zsys将这些自动生成的快照称为系统状态，zsysctl save将拍摄这些快照，zsysctl show将为我们提供保存了哪些状态集的高级概述。但是，目前还没有相应的zsysctl加载，在加载之前，尝试使用这些保存来实际从灾难中恢复的操作仍将比应有的操作多一点。

Ubuntu的ZFS安装程序将基础系统分割成令人眼花缭乱的21个独立的数据集，因此zsys确实需要高级的回滚助手。使用zfs命令本身回滚任何单个数据集非常容易-例如，zfs Rollback rpool/userdata/jim_v1qce1@autosys_pmxbuj-但我们预计用户在导航此类命令时不会感到愉快。

我们完全期待zsysctl最终会添加更容易回滚的功能。它只是还没有出现--至少在没有启用GRUB的引导菜单并重新启动的情况下是不会出现的。

虽然zsysctl不会在系统运行时公开状态加载功能，但这些功能在引导时出现在GRUB菜单中。然而，在使用默认设置的Ubuntu桌面安装上，GRUB菜单很难通过命令加载--按键的方式取决于UEFI或BIOS引导，而且时间也很危险。我们根本无法在我们的虚拟机上取消隐藏菜单，因为它的启动时间非常快。

您可以取消隐藏菜单并给自己几秒钟的时间来响应它，方法是使用sudo nano/etc/default/GRUB编辑GRUB默认值。在将GRUB_TIMEOUT_STYLE设置为MENU而不是HIDDEN，并给自己几秒钟时间使用GRUB_TIMEOUT=5进行响应之后，您将需要发出sudo update-GRUB命令来应用您的更改。当你这样做的时候，你会从os-prober中看到一个美观的错误，但是不要担心-它是无害的，而且你的更新实际上已经被应用了。

一旦我们可以实际看到GRUB菜单，我们就可以导航到History并看到一系列已保存的状态。对于每个州，我们可以选择仅恢复系统，也可以选择恢复系统和userdata-userdata，至少目前是这样，这意味着仅恢复主目录。不幸的是，没有仅恢复用户数据的选项。对于每个选项，您还可以选择是正常引导还是进入恢复模式。

我们有四个保存的状态可用，并决定拆分中间状态，仅恢复系统状态，返回两个快照。在系统完成引导(比正常时间稍长)之后，我们又看了一眼文件系统引擎盖下的情况。

系统挂载点看起来并没有什么不同--但仔细观察就会发现，引导环境仍然挂载了一些ZFS快照，而这通常是不会的。这看起来像是未能清理GRUB安装过程中发生的一些魔力，因为快照是以只读方式挂载在它们正常的.zfs目录中的，而不是挂载到生产文件系统会碰到它们的某个位置。

更重要的是，我们可以看到GRUB和zsys在ZFS层次结构中创建了一个全新的名称空间，即rpool/root/ubuntu_6toptv。我们仍然从最初的名称空间-ubuntu_w01csd-引导，但我们的两组较旧的快照或系统状态已移至较新的名称空间。

结果是，恢复到较早的系统状态似乎并不像通常的简单ZFS回滚操作那样是破坏性操作。我们一开始有四组快照，在恢复到较旧的快照后，仍有四组快照可用。

虽然它仍然是决定性的阿尔法-而且实际上还没有连接到运行-zsys也有一个自动修剪陈旧快照的设施。Zsys团队再次选择忽略现有的ZFS术语，将该服务称为垃圾收集服务，而不是将其命名为与快照本身有关的名称。

这里的词源学reboot似乎源于一种愿望，即让用户以包含多个分组快照的更高级别的术语进行思考。我们不太确定我们对此有何感想。如果处理得当，可能确实会减少最终用户的困惑。不过，sysadmin类型-无论是随意的还是专业的-更有可能受到脚本和现实之间的一层混淆的阻碍。现在，只有sysadmin类型的人才不会看到这些东西，因为它是下一个无法发现的最好的东西。

实际的工具使用命令jzsysctl service gc-a调用，该命令对系统上存在的所有zsys名称空间执行垃圾收集。如果您自己在相对较新的系统上运行该命令，您可能不会看到任何事情发生。它不会销毁任何快照，除非存在至少20个快照，然后根据年龄对它们进行精简。

垃圾收集规则集目前在zsys编译之前是可配置的，但在安装后无法访问-构建软件包后将其值硬编码到zsys和二进制文件中。就目前情况而言，最终用户和管理员无法访问这些参数。

正如Ubuntu开发者Didier Roche在Twitter上解释的那样，Ubuntu20.04系统目前还不能自动运行izsysctl服务GC。罗氏强烈建议暂时不要在任何生产系统上运行该命令，因为它是一个数据破坏功能，目前仍处于开发阶段。一旦它在测试和开发上有更多的时间，就会增加一个系统计时器来定期调用它。