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

特別提醒：本網內容轉載自其他媒體，目的在于傳遞更多信息，并不代表本網贊同其觀點。其原創性以及文中陳述文字和內容未經本站證實，對本文以及其中全部或者部分內容、文字的真實性、完整性、及時性本站不作任何保證或承諾，并請自行核實相關內容。本站不承擔此類作品侵權行為的直接責任及連帶責任。如若本網有任何內容侵犯您的權益，請及時聯系我們，本站將會在24小時內處理完畢。