上周 Linus Torvalds 在某个论坛上讨论关于内核的相关问题时，提到了 ZFS on Linux，他表明了自己的态度，在 Oracle 对 ZFS 的代码进行重新授权以使其能更友好地被引入到 Linux 内核主线之前，他不会推荐使用 ZFS，同时，即便抛开许可证的原因，Linus 也觉得 ZFS 的综合性能并不特别强。
本周，FOSS 作者 Jim Salter 针对 Linus 影响广泛的言论进行了回应，他觉得 Linus 对于 ZFS on Linux 不了解，表示“Linus 应当避免对自己不熟悉的项目发表权威性的言论”。
关于 ZFS on Linux 许可证方面的问题，要追溯到 2019 年 1 月，当时内核开发人员 Greg Kroah-Hartman 决定禁止将某些内核符号导出到非 GPL 可加载内核模块，这直接限制了 ZFS（一度引起 ZFS On Linux 在 Linux Kernel 5.0 上陷入困境）。
内核符号导出将有关内核状态的内部信息公开给可加载的内核模块，比如_kernel_fpu_跟踪处理器浮点单元的状态，无法访问该符号，ZFS 直接访问 FPU 的外部内核模块就必须实现自己的状态保存代码。具体来讲，拒绝继续导出_kernel_fpu_符号的技术影响不是防止模块直接访问 FPU，而是阻止模块使用内核的状态管理 工具 来保存和恢复状态。
因此，要删除对该符号的访问，就需要模块开发人员分别重新创建自己的状态保存代码，这会增加内核本身发生灾难性错误的可能性，因为恢复状态不正确可能会导致之后的内核操作崩溃。
另一方面，通常，在包括 BSD 在内的任何平台上，ZFS 都使用 SSE/AVX SIMD 矢量优化来加速某些操作，由于无法访问该_kernel_fpu_符号，ZFS 开发人员最初被迫完全禁用 SIMD 优化，这导致了相当大的性能下降。
许可证的问题不明确，所以内核人员才做出这样的限制，像此次 Linus 所说“老实说，在我收到 Oracle 的正式来信之前，我无法合并 ZFS 的任何工作。”、 “其他人认为将 ZFS 代码合并到内核中是可以的，并且模块接口可以使它正常，这是他们的决定。但是考虑到 Oracle 的诉讼性质以及许可方面的问题，我永远无法安心这样做。”
Linus 在讨论中继续说到 Linux 上包括 ZFS、Nvidia 专有图形驱动等在内的非 GPL 项目使用的内核模块“shim”在法律上的脆弱性。Jim 认为这里有一些问题，就是这是否构成“合理的防御”，也就是 20 年过去了，现在还没有人提出任何项目使用 LGPL shim 的问题。LGPL 内核模块 shim 的真正功能不是制裁使用非 GPL 代码接触内核，而是防止在 GPL 实施诉讼胜诉的情况下，保护 shim 另一端的专有代码不会被强制发布。关于脆弱性，Jim 认为至少到目前为止，一切都很好。
除了许可方面的讨论，Linus 认为他见过的基准测试也并没有使 ZFS 看起来那么出色，同时据他所知，ZFS 背后也没有任何真正的维护人员。这样的言论让 Jim 怀疑他是否实际使用过或认真研究过 ZFS。同时他指出此前 15 年中，Linus 也针对 ZFS 技术上的东西发表过评论，包括原子快照、快速复制、磁盘压缩、按块校验和自动数据修复等。
Jim 接下来在文章中针对这些问题给出回应，比如 ZFS 的逐块校验和自动数据修复功能在他自己的实际使用中多次防止了数据丢失，包括 SATA 控制器受到狂轰滥炸的特别糟糕的情况。一个标准的 RAID1 镜像本可以很好地返回 119GB 的坏数据，而不会发出任何警告，但是 ZFS 的实时校验和和错误检测使整个事情减轻到了不必备份的程度。比如原子快照可以在一个时间点上以一个块为单位保留完整的存储副本，而性能开销可以忽略不计，存储开销最小，并且这些快照的复制通常快数百或数千倍，比非文件系统集成的解决方案（如 rsync）更可靠。
最后 Jim 表示，ZFS 可能没有个人需要，但是把它贬低为什么也不是，似乎暴露出对它的无知。
猜你喜欢: