一百次开发冲刺，这是一个不错的整数……也是重新思考我们编写和发布报告方式的好时机。

是的，你没看错。如果四年半的时间可以被称为“传统”，那么这篇文章将是最后一篇遵循我们传统格式的文章（参见此处）。正如我们将在本文末尾解释的那样，后续报告将更像一个带有链接的信息摘要，而不是试图讲述故事的传统博客文章。

但故事时代尚未到来。让我们用一篇涵盖多个主题的最后一篇博客文章来结束故事时代

  • AutoYaST 的 `<partitioning>` 部分的更好编辑器
  • 改进 YaST 对高级 LVM 和 Btrfs 功能的支持
  • 确保 YaST 不落后于迁移到 `/usr/etc` 的步伐
  • 将 YaST 中的 XML 处理提升到一个新的水平

这些主题中的许多都明确面向中期未来，因此它们需要一些时间才能到达 openSUSE Leap 或 SUSE Linux Enterprise 的稳定版本。除非另有说明，否则本文描述的更改仅对 openSUSE Tumbleweed 用户可见。

AutoYaST UI：改进驱动器编辑

让我们从刚刚提到的规则的一个例外开始。也就是说，许多用户很快会在他们的系统中看到一些东西，因为我们计划将其作为 15.1 和 15.2 以及相应的 SLE 版本的维护更新发布。

作为 使 AutoYaST 现代化 的一部分，用于创建或编辑配置文件的分区部分的用户界面终于得到了改进。这意味着不再缺少诸如 Bcache、RAIDs、Btrfs 多设备文件系统等存储功能。

AutoYaST UI: drive section

除了允许设置 AutoYaST 分区部分支持的每个属性外，在重写期间，我们尝试使模块尽可能简单，以便于用户交互，不仅将字段分布到一起以放置相关内容，而不使界面拥挤，而且避免对每次更改进行警告和确认弹出窗口。

AutoYaST UI: partition section, general

当然，还有改进的空间，但至少我们迈出了第一步，摆脱了复杂且损坏的旧 UI，开始致力于更简单的 UI。

AutoYaST UI: partition section, usage

识别 LVM 高级功能

如你所知，YaST 可用于配置结合使用多种技术的存储设置，例如 MD RAID、bcache、Btrfs 和 LVM。由于会导致完全无法管理的界面和难以预测的行为，因此并非每项技术的每项功能都可以使用 YaST 进行调整。

但即使 YaST 无法创建某些高级配置，它也应该能够识别它们，在界面中显示它们，并允许进行简单的修改。

在过去的几个冲刺中，我们专注于教 YaST 如何处理 LVM 高级功能。现在它能够检测和使用 LVM RAID、镜像逻辑卷以及厚和薄 LVM 快照。

YaST 不允许创建此类设置，并且我们不计划在可预见的未来支持它。但是，已经使用这些 LVM 功能的用户现在可以使用 YaST 进行一些操作，并对他们的存储配置有更完整和准确的了解。此外，对这些技术的部分支持使得使用它们的系统的升级过程更加容易。

探测 Btrfs 快照关系和两个特殊之处

从纯技术层面来看，上述所有添加都意味着为所谓的设备图添加了新的可能性，该设备图由 libstorage-ng 用于表示任何系统。这包括表示 LVM 快照以及源和快照之间的关系。完成此操作后，应该很容易进一步识别和表示 btrfs 子卷的关系……除了两个特殊之处。

第一个是 btrfs 快照可以是同一个子卷的子项和快照。假设我们有一个 btrfs 安装在 /test。首先我们创建一个子卷，然后创建它的快照

cd /test
btrfs subvolume create origin
btrfs subvolume snapshot origin origin/snapshot

现在“快照”是“源”的子项，因为它位于“源”的目录结构中。在设备图中，这意味着我们有平行的边（灰色表示子项，绿色表示快照）

Btrfs subvolumes relations

第二个特殊之处来自于 btrfs 自由地重命名和移动子卷。我们可以将“源”移动到“快照”下

mv origin/snapshot .
mv origin snapshot

生成的设备图有一个循环

Btrfs subvolumes loop

到目前为止，这不可能发生，并且一些算法假定设备图始终是一个 有向无环图 (DAG)。为了解决这些算法，我们让它们在过滤后的设备图上运行，该设备图隐藏了快照关系。这些过滤器最近也已添加到 libstorage-ng 中，用于 LVM 快照。

现在 libstorage-ng 包含处理所有这些情况的机制，我们可以考虑在 YaST 中提供高级 Btrfs 选项。但这需要一些时间，因为它面临一些挑战，界面设计并不小。与此同时，只要启用新的变量“YAST_BTRFS_SNAPSHOT_RELATIONS”，就可以使用“libstorage-ng-utils”软件包中包含的“probe”命令来试用此新的 libstorage-ng 功能。

YAST_BTRFS_SNAPSHOT_RELATIONS=yes /usr/lib/libstorage-ng/utils/probe --display

自动检查新的 /usr/etc/ 文件

正如我们已经提到的 之前的报告 中，越来越多的发行版部分正在改变他们组织配置文件的方式。事情正在从单个配置文件从 `/etc` 移动到从 `/usr/etc` 开始并包含具有不同优先顺序的多个文件的分层结构。

YaST 开发人员需要知道何时更改了文件位置，以便我们可以调整 YaST 以读取和写入正确的位置。否则，很容易发生 YaST 更改被忽略的情况，稍后我们会收到错误报告。因此，我们实施了定期检查，扫描 Tumbleweed 中的所有 `etc` 配置文件，并报告新的未知文件。

该 脚本 每周自动在 Travis 上运行。它下载存储库元数据文件，其中包含所有软件包的文件列表。它还包含标记为“ghost”的文件，这些文件不是软件包的一部分，但可能由 RPM post-install 脚本或用户创建。我们只是将找到的文件与已知列表进行比较。

该脚本的一些实现细节可能对我们更技术性的读者来说很有趣，因为它解压缩 `*.xml.gz` 文件并在下载时解析 XML。这意味着它不需要将文件临时保存到磁盘或将其全部加载到内存中。这在这种情况下非常重要，因为解包后的 XML 非常大，它有 650MB 以上！

YaST 的 XML 解析器改进

说到技术细节，你可能还记得几轮冲刺前 我们提到 我们已经开始了一个小型的副项目来改进 YaST 的 XML 解析器。现在我们可以报告在该方面取得了重大进展。

首先要明确的是，我们不是试图通过编写另一个低级解析器来处理 XML 内部来重新发明轮子。我们依赖现有的解析器来重新思考 YaST 将数据序列化为 XML 及其返回的方式。所有这些都具有以下目标

  • 确保在数据转换为 XML 然后转换为原始数据时信息的一致性，使用我们以前的工具，一些信息在转换过程中会悄无声息地丢失。
  • 如果转换过程中出现任何问题，报告准确的错误，以便我们知道是否可以信任结果。
  • 能够在 (Auto)YaST 执行的早期阶段验证 XML。
  • 减少我们需要维护的代码量。
  • 使手动编写 XML 更容易。

我们写了许多关于我们如何实现每个目标的细节，只是意识到所有这些更适合于一个单独的专用博客文章。如果你对这些技术细节感兴趣，请继续关注。如果你不感兴趣，你可能会想知道这对你作为最终用户有什么影响。到目前为止，优势将特别对 AutoYaST 用户明显。更一致和更短的 XML 可以更轻松地编辑 AutoYaST 配置文件。模式验证允许在 XML 格式错误时提前发出警告。更精确的错误报告可以防止由 AutoYaST 配置文件中的错误引起的静默故障，这些错误可能导致系统出现后续问题。

我们继续前进

未来不仅会带来更好的 AutoYaST、更多的 LVM 和 Btrfs 功能或新的 XML 解析器。正如我们在本文开头提到的那样，我们还将稍微改变我们沟通每个 YaST 开发冲刺中实施的更改的方式。

我们目前每两周投入大量精力将所有信息整合到可以作为连贯且自包含的漂亮故事阅读的文本中，这并不总是那么容易。我们觉得现在是时候尝试另一种方法了。

从现在开始，我们的冲刺报告基本上将是 Github 上拉取请求的策划和组织列表。一方面，YaST 团队在编写全面且具有教学意义的每个拉取请求的描述方面付出了很多努力。另一方面，我们的读者通常对某些主题比对其他主题更感兴趣。因此，我们觉得这种摘要将提供一个很好的概述，允许读者通过检查相应拉取请求的描述来关注某些主题。

我们仍然会在此博客中发布这些摘要。并且我们将继续发布偶尔的额外帖子，专门针对单个主题，例如我们刚刚提到的有关改进的 XML 解析器的帖子。

所以，很快在我们的博客和所有通常的沟通渠道中与你见面……并继续享受乐趣！