正如本系列第 1 部分所讨论的，Stratis 是一个卷管理文件系统 (VMF)，其功能类似于 ZFS 和 Btrfs。在设计 Stratis 时，我们研究了现有解决方案的开发者所做的选择。
为什么不采用现有的解决方案？
原因各不相同。首先，让我们考虑 ZFS。ZFS 最初由 Sun Microsystems 为 Solaris 开发（现在归 Oracle 所有），已被移植到 Linux。然而，其 CDDL 许可的代码无法合并到 GPL 许可的 Linux 源代码树中。CDDL 和 GPLv2 是否真正不兼容是一个有争议的话题，但不确定性足以让企业 Linux 供应商不愿意采用和支持它。
Btrfs 也已得到充分的建立，并且没有许可问题。多年来，它一直是许多用户的“天选之子”，但它在稳定性和功能方面尚未达到所需的水平。
因此，在改善现状的愿望和对现有选项的沮丧情绪的推动下，Stratis 诞生了。
Stratis 的不同之处
ZFS 和 Btrfs 清楚地表明，将 VMF 编写为内核文件系统需要大量的工作和时间来解决错误并使其稳定。当涉及到宝贵的数据时，必须做到正确。从头开始，对 Stratis 采取相同的方法可能也需要十年时间，这是不可接受的。
相反，Stratis 选择使用 Linux 内核的其他现有功能：设备映射器子系统，LVM 最显著地使用它在块设备之上提供 RAID、精简配置和其他功能；以及经过良好测试且高性能的 XFS 文件系统。Stratis 使用现有技术层构建其池，目标是管理它们，使其对用户而言看起来像一个无缝的整体。
Stratis 从 ZFS 中学到了什么
对于许多用户来说，ZFS 为下一代文件系统应该是什么设定了期望。阅读网上人们谈论 ZFS 的评论有助于设定 Stratis 的初始开发目标。ZFS 的设计也隐含地突出了要避免的事情。例如，ZFS 在附加在另一个系统上创建的池时需要一个“导入”步骤。这有很多原因，每个原因都可能是 Stratis 必须解决的问题，无论是采用相同的方法还是不同的方法。
我们不喜欢 ZFS 的一件事是，它对添加新硬盘驱动器或用更大的驱动器替换现有驱动器有一些限制，特别是如果池配置为冗余。当然，这是有原因的，但我们认为这是一个我们可以改进的领域。
最后，一旦学会使用 ZFS 的命令行工具，就会有很好的体验。我们希望 Stratis 的命令行工具也能有同样的感觉，并且我们也喜欢该工具倾向于使用位置参数并限制每个命令所需的输入量。
Stratis 从 Btrfs 中学到了什么
我们喜欢 Btrfs 的一点是，它具有带有位置子命令的单个命令行工具。Btrfs 还将冗余（Btrfs 配置文件）视为池的属性，这似乎比 ZFS 的方法更容易理解，并且允许添加甚至删除驱动器。
最后，查看 ZFS 和 Btrfs 都提供的功能，例如快照实现和发送/接收支持，有助于确定 Stratis 应包含哪些功能。
Stratis 从 LVM 中学到了什么
从 Stratis 的早期设计阶段开始，我们就对 LVM 进行了广泛的研究。LVM 是目前 Linux 设备映射器 (DM) 子系统最重要的用户——事实上，DM 由 LVM 核心团队维护。我们从实际使用 LVM 作为 Stratis 层以及使用 DM 的示例（Stratis 可以直接与 LVM 对等）的可能性方面对其进行了检查。我们查看了 LVM 的磁盘元数据格式（以及 ZFS 和 XFS 的格式），以获得定义 Stratis 的磁盘元数据格式的灵感。
在列出的项目中，LVM 在内部与 Stratis 最为相似，因为它们都使用 DM。然而，从使用角度来看，LVM 对其内部工作原理更加透明。这为专家用户提供了大量控制和选项，可以精确地配置卷组（池）布局，而 Stratis 则没有。
解决方案的多样性
在自由软件和开源软件上工作的一大优点是没有不可替代的组件。每个部分——甚至内核——都开放供查看、修改，甚至在当前软件无法满足用户需求时进行替换。如果对两者都有足够的支持以并行维持，则新项目不需要结束现有项目。
Stratis 旨在更好地满足一些用户对本地存储管理的需求——那些寻求无忧、易用、强大解决方案的用户。这意味着做出可能不适合所有用户的设计选择。替代方案使艰难的选择成为可能，因为用户有其他选择。所有用户最终都受益于他们使用最适合他们的工具的能力。
3 条评论