正如本系列第 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 条评论