上週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 可能沒有個人需要，但是把它貶低為什麼也不是，似乎暴露出對它的無知。