ZFS 是一個擁有邏輯捲軸管理功能的檔案系統，最早源自於昇陽電腦在 2001 年開始為 Solaris 作業系統開發的檔案系統。ZFS 具有可擴充套件性，並且包括大量保護措施防止資料損壞，支援高儲存容量、高效資料壓縮、整合檔案系統、、快照和寫入時複製、連續完整性檢查與自動修復、RAIDZ、原生 NFSv4 ACL 等功能，並且能被精確配置。ZFS 有兩個主要實現，分別來自 Oracle 和 OpenZFS，它們之間極度相似，這使得 ZFS 在類 Unix 系統中廣泛可用。 ZFS 這一名字本身沒有含義 Zettabyte File System，也不是某種縮寫。ZFS 最初是專有軟體，被 Sun 內部開發作為 Solaris 的一部分，由 Sun 儲存部門的 CTO、研究員帶領團隊開發。在 2005 年，Solaris 的大部分，包括 ZFS 成為採用通用開發與散佈許可證的開源軟體，作為 OpenSolaris 專案。在 2006 年，ZFS 成為 Solaris 的一項標準特性。 在 2010 年，Sun 被 Oracle 收購，ZFS 成為 Oracle 的註冊商標。Oracle 停止為 OpenSolaris 和 ZFS 專案提供更新的原始碼，使得 Oracle 的 ZFS 轉為閉源。因此，有人成立了 illumos 專案，去維護已經存在的開源的 Solaris 程式碼，並且在 2013 年成立 OpenZFS 以配合 ZFS 的開源發展。OpenZFS 維護管理核心 ZFS 程式碼，而一些使用 ZFS 的組織維護特定的程式碼和 ZFS 所需要的驗證過程，以整合到他們的系統。OpenZFS 在類 Unix 系統中被廣泛使用。 歷史 ZFS 的設計與開發由 Sun 公司的 Jeff Bonwick 所領導的一支團隊完成。最早宣佈於 2004 年 9 月 14 日，於 2005 年 10 月 31 日併入了 Solaris 開發的主幹原始碼。並在 2005 年 11 月 16 日作為 OpenSolaris build 27 的一部分發布。Sun 在 OpenSolaris 社群開張 1 年後的 2006 年六月，將 ZFS 整合進了 Solaris 10 606 版本更新。 ZFS 的命名來源發想於 Zettabyte File System 的首字母縮寫。但 ZFS 本身並不具備任何的縮寫意涵，只是作者想闡述做為一個具備高擴充容量檔案系統且還有支援許多延伸功能的一個產品。 儲存池 不同於傳統檔案系統需要駐留於單獨裝置或者需要一個卷管理系統去使用一個以上的裝置，ZFS 建立在虛擬的，被稱為 zpools 的儲存池之上（儲存池最早在 AdvFS 實現，並且加到後來的 Btrfs）。每個儲存池由若干虛擬裝置（virtual devices，vdevs）組成。這些虛擬裝置可以是原始磁碟，也可能是一個 RAID1 映象裝置，或是非標準 RAID 等級的多磁碟組。於是 zpool 上的檔案系統可以使用這些虛擬裝置的總儲存容量。 可以使用以及設定磁碟預留空間來限制儲存池中單個檔案系統所佔用的空間。 容量 ZFS 是一個 128 位的檔案系統，這意味著它能儲存 1800 億億（1841018）倍於當前 64 位檔案系統的資料。ZFS 的設計如此超前以至於這個極限就當前現實實際可能永遠無法遇到。專案領導 Bonwick 曾說：要填滿一個 128 位的檔案系統，將耗盡地球上所有儲存裝置。除非你擁有煮沸整個海洋的能量，不然你不可能將其填滿。 以下是 ZFS 的一些理論極限： 248 任意檔案系統的快照數量（21014） 248 任何單獨檔案系統的檔案數（21014） 16 exabytes 264 byte 檔案系統最大尺寸 16 exabytes 264 byte 最大單個檔案尺寸 16 exabytes 264 byte 最大屬性大小 128 Zettabytes 278 byte 最大 zpool 大小 256 單個檔案的屬性數量（受 ZFS 檔案數量的約束，實際為 248） 256 單個目錄的檔案數（受 ZFS 檔案數量的約束，實際為 248） 264 單一 zpool 的裝置數 264 系統的 zpools 數量 264 單一 zpool 的檔案系統數量 作為對這些數字的感性認識，假設每秒鐘建立 1000 個新檔案，達到 ZFS 檔案數極限需要大約 9000 年。 在辯解填滿 ZFS 與煮沸海洋的關係時，Bonwick 寫到： 儘管我們都希望摩爾定律永遠延續，但是量子力學給定了任何物理裝置上計算速率（computation rate）與資訊量的理論極限。舉例而言，一個 zhhanszhhant 質量 為 1 公斤，體積為 1 升的物體，每秒至多在 1031 位資訊 上進行 1051 次運算 Seth Lloyd Ultimate physical limits to computation（計算的終極物理限制） Nature 406 10471054 2000。一個完全的 128 位儲存池將包含 2128 個塊 2137 位元組 2140 位；應此，儲存這些資料位至少需要 2140 位 1031 位 公斤 1360 億公斤的物質。 寫入時複製事務模型 ZFS 採用寫入時複製事務物件模型。檔案系統中的所有塊指向都包含目標塊的 256 位校驗和或 hash 值（目前有、 Fletcher4 與 SHA2 供選擇） 見 24 節。。在讀取塊時會對這些引數加以驗證。包含活動資料的塊不會被覆蓋，而是給修改過的資料分配一個新塊，任何引用此塊的元資料塊都被重新讀取、重新分配和重寫。為減少該過程的開銷，多次讀寫更新會被歸納為一個事件組，在需要同步寫入語義時會使用 ZIL寫入快取，而這些塊會與校驗和一同編入中。 利用寫入時複製使 ZFS 的快照和事務功能的實現變得更簡單和自然，快照功能更靈活，但嚴重碎片化問題是其缺點之一。對於透過順序寫生成的大檔案，如果以後隨機的對其中的一部分進行了更改，那麼這個檔案在硬碟上的物理地址就變得不再連續，未來的順序讀會變得效能比較差。 快照與克隆 當 ZFS 寫入新資料時，可以保留包含舊資料的塊，因而能夠維護檔案系統的快照版本。ZFS 快照具備一致性（快照基於單個時間點反映整個資料）。而因為組合快照的所有資料都會被儲存，且整個儲存池通常每小時會進行幾次快照，所以快照的建立速度非常快。任何未變動的資料會在檔案系統及其快照之間進行共享，因此也具備空間高效性。快照本質上是隻讀的，確保在建立後快照不會被修改。快照可以被整個恢復，也可以恢復快照中的某些檔案或目錄。 ZFS 也可以建立可寫快照（克隆），讓兩個獨立的檔案系統共享一組塊。對克隆檔案系統的修改都會建立新的資料塊以反映這些更改。但是無論存在多少個克隆，未變動的塊仍然會被共享。這是寫入時複製原則的實施方式。 動態條帶化 ZFS 能動態條帶化所有裝置以最大化吞吐量。當額外的裝置被加入到 zpool 中的時候，條頻寬度會自動 zhhanszhhant 擴充套件 以包含這些裝置。這使得儲存池中的所有磁碟都被用到，同時負載被平攤到所有的磁碟上。 可變塊尺寸 ZFS 使用可變大小的塊，最大可至 128KB。現有的程式碼允許管理員調整最大塊大小，這在大塊效果不好的時候有用。未來也許能做到自動調整適合工作量的塊大小。需要引用 ZFS 的可變大小的塊與 BtrFS 和 Ext4 的 extent 不同。在 ZFS 中，在一個檔案中所有資料塊的邏輯長度必須是相同的，不同檔案之間的塊大小可以不同，因此 ZFS 可以用直接對映（direct map）的方式（同 ufsffsext2ext3）來來搜尋間接塊的資料指標陣列（blkptr）。BtrFS 和 Ext4 的 extent 方式在同一個檔案中每個資料快的大小都可以不相同，因此需要用 B Tree 或者類 B Tree 的方式來組織間接塊的資料。 雖然直接對映方式比 B Tree 的查詢速度快，但是這種方式的缺點也非常明顯，如：元資料開銷過大、順序 IO 的大檔案效能不好、刪除比較慢等等，因此在現代檔案系統中對映方式逐漸被 extent 變長塊取代。 如果資料壓縮（LZJB）被啟用，可變塊大小需要被用到。如果一個數據塊可被壓縮至一個更小的資料塊，則小的資料塊將使用更少的儲存和提高吞吐量（代價是增加 CPU 壓縮和解壓縮的負擔）。 輕量化檔案系統建立 在 ZFS 中，儲存池中檔案系統的操作相比傳統檔案系統的卷管理更加便捷。建立 ZFS 檔案系統或者改變一個 ZFS 檔案系統的大小接近於傳統技術中的管理目錄而非管理卷。 儲存管理 限制 ZFS 的最新 beta 版已支援透明加密。 專利爭端 NetApp 指控 Sun 的 ZFS 檔案系統侵犯了它 WAFL 的七項專利，Sun 反訴 NetApp 侵犯了 12 項專利，其中包括 NFS 協議等。後來專利爭端以和解告終。 對其支援的作業系統 Sun Solaris OpenSolaris Illumos 發行版 OpenIndiana FreeBSD Mac OS X Server 105 NetBSD Linux（透過使用者空間檔案系統或原生第三方核心可載入核心模組支援） 參見 Btrfs OpenZFS 參考文獻 外部連結 ZFS 主頁 ZFS on Linux 美國勞倫斯利福摩爾國家實驗室的 ZFS on Linux 開源計劃 Category 磁碟檔案系統 Category 昇陽電腦軟體 CategoryLinux 檔案系統 CategoryOpenSolaris