ZFS

ZFS是一個擁有邏輯捲軸管理功能的檔案系統，最早源自於昇陽電腦在2001年開始為Solaris操作系統開發的文件系統。ZFS具有可擴展性，並且包括大量保護措施防止數據損壞，支持高存儲容量、高效數據壓縮、集成文件系統、Volume (computing)、快照和寫入時複製、連續完整性檢查與自動修復、RAID-Z、原生NFSv4 ACL等功能，並且能被精確配置。ZFS有兩個主要實現，分別來自Oracle和OpenZFS，它們之間極度相似，這使得ZFS在類Unix系統中廣泛可用。
ZFS這一名字本身沒有含義，也不是某種縮寫，曾被認為表示Zettabyte File System。ZFS最初是專有軟件，被Sun內部開發作為Solaris的一部分，由Sun存儲部門的CTO、研究員Jeff Bonwick帶領團隊開發。在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 6/06版本更新。
ZFS的命名來源發想於"Zettabyte File System"的首字母縮寫。但ZFS本身並不具備任何的縮寫意涵，只是作者想闡述做為一個具備高擴充容量檔案系統且還有支援許多延伸功能的一個產品。

**存儲池**
不同於傳統文件系統需要駐留於單獨設備或者需要一個卷管理系統去使用一個以上的設備，ZFS建立在虛擬的，被稱為“zpools”的存儲池之上（存儲池最早在AdvFS實現，並且加到後來的Btrfs）。每個存儲池由若干虛擬設備（virtual devices，vdevs）組成。這些虛擬設備可以是原始磁盤，也可能是一個RAID1鏡像設備，或是非標準RAID等級的多磁盤組。於是zpool上的文件系統可以使用這些虛擬設備的總存儲容量。
可以使用Disk_quota以及設置磁盤預留空間來限制存儲池中單個文件系統所佔用的空間。

**容量**
ZFS是一個128位的文件系統，這意味著它能存儲1800京（1.84×1019）倍於當前64位文件系統的數據。ZFS的設計如此超前以至於這個極限就當前現實實際可能永遠無法遇到。項目領導Bonwick曾說：“要填滿一個128位的文件系統，將耗盡地球上所有存儲設備。除非你擁有煮沸整個海洋的能量，不然你不可能將其填滿。”
以下是ZFS的一些理論極限：- 248—任意文件系統的快照數量（2×1014）- 248—任何單獨文件系統的文件數（2×1014）- 16 EiB (264 字節)—文件系統最大尺寸- 16 EiB (264 字節)—最大單個文件尺寸- 16 EiB (264 字節)—最大屬性大小- ~2.88×1015 ZiB (2128 字節)—最大zpool大小- 256—單個文件的屬性數量（受ZFS文件數量的約束，實際為248）- 256—單個目錄的文件數（受ZFS文件數量的約束，實際為248）- 264—單一zpool的設備數- 264—系統的zpools數量- 264—單一zpool的文件系統數量
作為對這些數字的感性認識，假設每秒鐘創建1,000個新文件，達到ZFS文件數極限需要大約9,000年。
在辯解填滿ZFS與煮沸海洋的關係時，Bonwick寫到：
儘管我們都希望摩爾定律永遠延續，但是量子力學給定了任何物理設備上計算速率（computation rate）與信息量的理論極限。舉例而言，一個-{zh-hans;zh-hant|質量}-為1公斤，體積為1升的物體，每秒至多在1031位信息
上進行1051次運算。一個完全的128位存儲池將包含2128個塊 2137字節 2140位；應此，保存這些數據位至少需要(2140位) / (1031位/公斤)  1360億公斤的物質。

**寫入時複製事務模型**
ZFS採用寫入時複製事務對象模型。文件系統中的所有塊指向都包含目標塊的256位校驗和或hash值（目前有Fletcher's checksum、 Fletcher-4與SHA-2供選擇）。在讀取塊時會對這些參數加以驗證。包含活動數據的塊不會被覆蓋，而是給修改過的數據分配一個新塊，任何引用此塊的元數據塊都被重新讀取、重新分配和重寫。為減少該過程的開銷，多次讀寫更新會被歸納為一個事件組，在需要同步寫入語義時會使用ZIL（intent log）寫入緩存，而這些塊會與校驗和一同編入Merkle tree中。
利用寫入時複製使ZFS的快照和事務功能的實現變得更簡單和自然，快照功能更靈活，但嚴重碎片化問題是其缺點之一。對於通過順序寫生成的大文件，如果以後隨機的對其中的一部分進行了更改，那麼這個文件在硬盤上的物理地址就變得不再連續，未來的順序讀會變得性能比較差。

**快照與克隆**
當ZFS寫入新數據時，可以保留包含舊數據的塊，因而能夠維護文件系統的快照版本。ZFS快照具備一致性（快照基於單個時間點反映整個數據）。而因為組合快照的所有數據都會被儲存，且整個存儲池通常每小時會進行幾次快照，所以快照的創建速度非常快。任何未變動的數據會在文件系統及其快照之間進行共享，因此也具備空間高效性。快照本質上是隻讀的，確保在創建後快照不會被修改。快照可以被整個恢復，也可以恢復快照中的某些文件或目錄。
ZFS也可以創建可寫快照（“克隆”），讓兩個獨立的文件系統共享一組塊。對克隆文件系統的修改都會創建新的數據塊以反映這些更改。但是無論存在多少個克隆，未變動的塊仍然會被共享。這是寫入時複製原則的實施方式。

**動態條帶化**
ZFS能動態條帶化所有設備以最大化吞吐量。當額外的設備被加入到zpool中的時候，條帶寬度會自動-{zh-hans;zh-hant|擴展}-以包含這些設備。這使得存儲池中的所有磁盤都被用到，同時負載被平攤到所有的磁盤上。

**可變塊尺寸**
ZFS使用可變大小的塊，最大可至128 KB。現有的代碼允許管理員調整最大塊大小，這在大塊效果不好的時候有用。未來也許能做到自動調整適合工作量的塊大小。需要引用
ZFS的可變大小的塊與BtrFS和Ext4的extent不同。在ZFS中，在一個文件中所有數據塊的邏輯長度必須是相同的，不同文件之間的塊大小可以不同，因此ZFS可以用直接映射（direct map）的方式（同ufs/ffs/ext2/ext3）來來搜索間接塊的數據指針數組（blkptr）。BtrFS和Ext4的extent方式在同一個文件中每個數據快的大小都可以不相同，因此需要用B+樹或者類B樹的方式來組織間接塊的數據。
雖然直接映射方式比B+樹的查找速度快，但是這種方式的缺點也非常明顯，如：元數據開銷過大、順序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 10.5
*NetBSD
*Linux（通過用戶空間文件系統或原生第三方內核可載入核心模組支持）

**參見**
 Btrfs- OpenZFS

**參考文獻**

**外部連結**
  ZFS主頁-  ZFS on Linux date=20220517072313  - 美國勞倫斯利福摩爾國家實驗室的ZFS on Linux開源計劃