上周 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/AVXSIMD矢量優化來加速某些操作，由于無法訪問該_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 可能沒有個人需要，但是把它貶低為什么也不是，似乎暴露出對它的無知。

總結

以上是生活随笔為你收集整理的Linus Tovalds，你根本不懂 ZFS的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。