Linux上的原生ZFS支持完备功能
2016-04-06 17:27:42 
阿炯
ZFS for Linux（ZoL）的开发者们又发布了一个 GNU/Linux 系统上的 ZFS 原生实现的稳定版本，Ubuntu 将正式支持 ZFS 文件系统。
在 Linux 中使用 ZFS 的两种方法。第一种使用了用户空间文件系统(Filesystem in Userspace，FUSE)系统来推动 ZFS 文件系统到用户空间以便避免许可问题；第二种方法是一个 ZFS 本机端口，用于集成到 Linux 内核，同时避免知识产权问题。
ZFS 是一个高级的文件系统和卷管理器，ZFS for Linux 在 Linux 内核中原生实现了 ZFS 文件系统。当前最新的稳定版本 ZFS for Linux 0.6.5.6 带来了一些有趣的更新，比如支持从 2.6.32 到 4.5 的 Linux 内核，也支持了 s390 和 s390x 硬件架构。 据该项目的 GitHub 主页上的发布公告，软件包已经更新，移除了人为的硬件架构限制，ZVOL 小操作更加健壮、支持了移步模式；正确地解析了 zdb -R 参数；zpool 子命令增加了 “-gLP”参数；zpool_find_vdev() 函数现在不再截断 vdev 路径；修复了“zpool list -v”命令对日志设备和空闲设备的输出。
从现在起， ZFS for Linux 现在已经功能完备，带来了稳定而功能完备的 ZPL、ZVOL、SPA 和 DMU 层。可从项目网站上下载 ZFS for Linux 0.6.5.6，以及找到相应的安装指导。
数据丢失导致 ZFS on Linux 进行了一次快速升级
2018年04月11日，Linux 文件系统和卷管理器 ZFS on Linux Linux 0.7.7版本被曝存在“Unlistable and disappearing files”问题，用户在复制具有大量文件的目录时会丢失数据。在问题出现后，维护者迅速发布了一个新版本，从0.7.7 更新到了 0.7.8。
问题描述中称：“复制具有大量文件的目录时发生数据丢失。例如，在 SRC 有10000个文件的情况下，命令cp -r SRC DST 很可能会引发错误‘cp：无法创建常规文件 DST / XXX：设备上空间不足’，同时 DST 目录中会丢失数千文件。(不用说，存储空间是足够的)”
用户在不同 Linux 版本下验证了该问题，并在社区讨论相应解决方法。很快问题原因被找到，维护者进行了处理，对0.7.7版本做了很小的改动，并迅速发布0.7.8版本。值得一提的是，从4月7日问题被曝光到修复完成，一共只用了3天时间。
ZFS On Linux 0.8.0 发布，新增原生加密支持
Linux 文件系统和卷管理器 ZFS On Linux 0.8.0 在2019年5月发布了，此版本增加了原生加密支持与原始加密内容"zfs send/receive"支持。encryption 属性允许创建加密的文件系统和卷，默认情况下使用 aes-256-ccm 算法，并使用 zfs load-key 和关联的子命令管理每个数据集密钥。
zfs send -w 选项允许将加密数据集发送和接收到另一个池而无需解密，接收的数据集受发送方的原始用户密钥保护。这样可以有效地将数据集备份到不受信任的系统，而不必担心数据受到损害。此外 0.8.0 版本还带来了其它特性，包括：
支持设备删除
池检查点
池初始化支持
Python 3 与其工具的兼容性
添加对 Linux 直接 IO 接口的支持
各种性能改进
详情查看更新说明。
Linus Torvalds 不建议使用 ZFS On Linux
2020年01月10日，Linux 内核创建者 Linus Torvalds 回应了 Linux 内核调度器存在问题的文章引发了大家的关注，在同一个帖子里，他还回复了一名用户抱怨 Linux 内核最近破坏了内核源码树外 ZFS 模块的评论。
Linus 表明了自己对 ZFS On Linux 的态度，在 Oracle 对 ZFS 的代码进行重新授权以使其能更友好地被引入到 Linux Kernel mainline 之前，他不会推荐使用 ZFS On Linux。不过即便抛开许可证的原因，Linus 似乎也没被 ZFS 的功能或综合表现所吸引。当然，Linus Torvalds 对内核源码树外模块的行为几乎不怎么控制，并且始终坚守不维护不稳定的驱动程序 API/ABI 的立场，不会投入精力到闭源/内核源码树外的代码中。内核源码树外的模块也基本上被视为不存在。
根据 Linus 的回应，如果有人为 Linux 内核添加了像 ZFS 这样的模块，那么它们将独立于 Linux 内核，Linus 也无法维护它，也无法被其他人提交的内核变更所影响。有人认为将 ZFS 代码合并到内核中是可行的，但 Linus 考虑到 Oracle 的诉讼性质，以及有关许可的问题，他绝对无法放心采用这种方式。Linus 还坦言对某些"ZFS shim layer"东西完全不感兴趣，有些人似乎认为这会隔离两个项目。但这对 Linux 内核没有任何价值，并且考虑到 Oracle 关于 API 的版权诉讼（请参阅 Java），他不认为 Oracle 会修改 ZFS 的许可证。
总而言之，Linus 的观点就是不要使用 ZFS。他表示自己见过的基准测试并没有使 ZFS 看起来那么出色。据他所知，ZFS 背后也没有任何真正的维护人员。因此，从长期稳定性的角度来看，为什么首先要使用它？
关于ZFS FOSS 作者 Jim Salter 针对 Linus 进行了回应
2020年01月14日，上周 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 可能没有个人需要，但是把它贬低为什么也不是，似乎暴露出对它的无知。
ZFS On Linux 在 Linux Kernel 5.x 上陷入了困境
Linux Kernel 5.0 首个 RC 版已发布，5.x 是一个重要的版本，带来了许多的功能和改进，但对于那些依赖 ZFS On Linux (ZOL) 的用户，可能暂时不会希望尝鲜使用 Linux Kernel 5.0 的候选发布版本。原因在于ZFS On Linux 目前无法针对 Linux Kernel 5.0 源码进行构建。这不是由于一个简单的 API 变更而导致的，而是 5.0 内核不会再导出 __kernel_fpu_begin 和 __kernel_fpu_end 符号，恰好 ZOL 内核模块依赖这些符号作为文件系统校验的一部分。
由于与内核源码树外的 ZOL 内核代码存在许可证兼容性问题，所以目前不能马上提供一个简单的解决方案，尤其是不涉及使用 GPL 符号的解决方案。虽然将来肯定会有时间和新代码可以实现解决方案，不过目前看来，似乎上游的内核开发者对任何专门帮助 ZOL 的操作并不感兴趣（或者很少有关于该问题的源码树外模块）。为此，Linux 内核社区的二把手 Greg KH 也不得不出面来说明他对 ZFS On Linux 的看法以及当前的问题：对 ZFS 几乎是零容忍的态度。因为 Sun 曾明确地表示不希望他们的代码在 Linux 上运行，所以为什么我们要做额外的工作来让他们的代码正常运行？
有关 ZOL 和 Linux Kernel 5.0 的情况来看，双方都在泥潭中无法自拔。
在 Linux 中使用 ZFS 的两种方法。第一种使用了用户空间文件系统(Filesystem in Userspace，FUSE)系统来推动 ZFS 文件系统到用户空间以便避免许可问题；第二种方法是一个 ZFS 本机端口，用于集成到 Linux 内核，同时避免知识产权问题。
ZFS 是一个高级的文件系统和卷管理器，ZFS for Linux 在 Linux 内核中原生实现了 ZFS 文件系统。当前最新的稳定版本 ZFS for Linux 0.6.5.6 带来了一些有趣的更新，比如支持从 2.6.32 到 4.5 的 Linux 内核，也支持了 s390 和 s390x 硬件架构。 据该项目的 GitHub 主页上的发布公告，软件包已经更新，移除了人为的硬件架构限制，ZVOL 小操作更加健壮、支持了移步模式；正确地解析了 zdb -R 参数；zpool 子命令增加了 “-gLP”参数；zpool_find_vdev() 函数现在不再截断 vdev 路径；修复了“zpool list -v”命令对日志设备和空闲设备的输出。
从现在起， ZFS for Linux 现在已经功能完备，带来了稳定而功能完备的 ZPL、ZVOL、SPA 和 DMU 层。可从项目网站上下载 ZFS for Linux 0.6.5.6，以及找到相应的安装指导。
数据丢失导致 ZFS on Linux 进行了一次快速升级
2018年04月11日，Linux 文件系统和卷管理器 ZFS on Linux Linux 0.7.7版本被曝存在“Unlistable and disappearing files”问题，用户在复制具有大量文件的目录时会丢失数据。在问题出现后，维护者迅速发布了一个新版本，从0.7.7 更新到了 0.7.8。
问题描述中称：“复制具有大量文件的目录时发生数据丢失。例如，在 SRC 有10000个文件的情况下，命令cp -r SRC DST 很可能会引发错误‘cp：无法创建常规文件 DST / XXX：设备上空间不足’，同时 DST 目录中会丢失数千文件。(不用说，存储空间是足够的)”
用户在不同 Linux 版本下验证了该问题，并在社区讨论相应解决方法。很快问题原因被找到，维护者进行了处理，对0.7.7版本做了很小的改动，并迅速发布0.7.8版本。值得一提的是，从4月7日问题被曝光到修复完成，一共只用了3天时间。
ZFS On Linux 0.8.0 发布，新增原生加密支持
Linux 文件系统和卷管理器 ZFS On Linux 0.8.0 在2019年5月发布了，此版本增加了原生加密支持与原始加密内容"zfs send/receive"支持。encryption 属性允许创建加密的文件系统和卷，默认情况下使用 aes-256-ccm 算法，并使用 zfs load-key 和关联的子命令管理每个数据集密钥。
zfs send -w 选项允许将加密数据集发送和接收到另一个池而无需解密，接收的数据集受发送方的原始用户密钥保护。这样可以有效地将数据集备份到不受信任的系统，而不必担心数据受到损害。此外 0.8.0 版本还带来了其它特性，包括：
支持设备删除
池检查点
池初始化支持
Python 3 与其工具的兼容性
添加对 Linux 直接 IO 接口的支持
各种性能改进
详情查看更新说明。
Linus Torvalds 不建议使用 ZFS On Linux
2020年01月10日，Linux 内核创建者 Linus Torvalds 回应了 Linux 内核调度器存在问题的文章引发了大家的关注，在同一个帖子里，他还回复了一名用户抱怨 Linux 内核最近破坏了内核源码树外 ZFS 模块的评论。
Linus 表明了自己对 ZFS On Linux 的态度，在 Oracle 对 ZFS 的代码进行重新授权以使其能更友好地被引入到 Linux Kernel mainline 之前，他不会推荐使用 ZFS On Linux。不过即便抛开许可证的原因，Linus 似乎也没被 ZFS 的功能或综合表现所吸引。当然，Linus Torvalds 对内核源码树外模块的行为几乎不怎么控制，并且始终坚守不维护不稳定的驱动程序 API/ABI 的立场，不会投入精力到闭源/内核源码树外的代码中。内核源码树外的模块也基本上被视为不存在。
根据 Linus 的回应，如果有人为 Linux 内核添加了像 ZFS 这样的模块，那么它们将独立于 Linux 内核，Linus 也无法维护它，也无法被其他人提交的内核变更所影响。有人认为将 ZFS 代码合并到内核中是可行的，但 Linus 考虑到 Oracle 的诉讼性质，以及有关许可的问题，他绝对无法放心采用这种方式。Linus 还坦言对某些"ZFS shim layer"东西完全不感兴趣，有些人似乎认为这会隔离两个项目。但这对 Linux 内核没有任何价值，并且考虑到 Oracle 关于 API 的版权诉讼（请参阅 Java），他不认为 Oracle 会修改 ZFS 的许可证。
总而言之，Linus 的观点就是不要使用 ZFS。他表示自己见过的基准测试并没有使 ZFS 看起来那么出色。据他所知，ZFS 背后也没有任何真正的维护人员。因此，从长期稳定性的角度来看，为什么首先要使用它？
关于ZFS FOSS 作者 Jim Salter 针对 Linus 进行了回应
2020年01月14日，上周 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 可能没有个人需要，但是把它贬低为什么也不是，似乎暴露出对它的无知。
ZFS On Linux 在 Linux Kernel 5.x 上陷入了困境
Linux Kernel 5.0 首个 RC 版已发布，5.x 是一个重要的版本，带来了许多的功能和改进，但对于那些依赖 ZFS On Linux (ZOL) 的用户，可能暂时不会希望尝鲜使用 Linux Kernel 5.0 的候选发布版本。原因在于ZFS On Linux 目前无法针对 Linux Kernel 5.0 源码进行构建。这不是由于一个简单的 API 变更而导致的，而是 5.0 内核不会再导出 __kernel_fpu_begin 和 __kernel_fpu_end 符号，恰好 ZOL 内核模块依赖这些符号作为文件系统校验的一部分。
由于与内核源码树外的 ZOL 内核代码存在许可证兼容性问题，所以目前不能马上提供一个简单的解决方案，尤其是不涉及使用 GPL 符号的解决方案。虽然将来肯定会有时间和新代码可以实现解决方案，不过目前看来，似乎上游的内核开发者对任何专门帮助 ZOL 的操作并不感兴趣（或者很少有关于该问题的源码树外模块）。为此，Linux 内核社区的二把手 Greg KH 也不得不出面来说明他对 ZFS On Linux 的看法以及当前的问题：对 ZFS 几乎是零容忍的态度。因为 Sun 曾明确地表示不希望他们的代码在 Linux 上运行，所以为什么我们要做额外的工作来让他们的代码正常运行？
有关 ZOL 和 Linux Kernel 5.0 的情况来看，双方都在泥潭中无法自拔。