ZFS

本頁使用了標題或全文手工轉換
維基百科，自由的百科全書
ZFS
開發者甲骨文公司
全稱ZFS
發布2005年11月 (OpenSolaris)
結構
目錄內容可擴展哈希表
限制
最大文件尺寸264字節（16 Exabytes)
最大文件數量248
最長文件名255字節
最大卷容量264字節（16 exabytes）
功能
岔流是（稱作擴展文件屬性）
屬性POSIX
文件系統權限POSIX、NFSv4 ACLs
透明壓縮是
透明加密是
重複數據刪除是
操作系統支持見下

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（英語：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日，[1]於2005年10月31日併入了Solaris開發的主幹源代碼。[2]並在2005年11月16日作為OpenSolaris build 27的一部分發布。Sun在OpenSolaris社區開張1年後的2006年六月，將ZFS整合進了Solaris 10 6/06版本更新。[3]

ZFS的命名來源發想於"Zettabyte File System"的首字母縮寫。[4]但ZFS本身並不具備任何的縮寫意涵，只是作者想闡述做為一個具備高擴充容量檔案系統且還有支援許多延伸功能的一個產品。

存儲池

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

可以使用磁盤限額（英語：Disk_quota）以及設置磁盤預留空間來限制存儲池中單個文件系統所占用的空間。

容量

ZFS是一個128位的文件系統，這意味着它能存儲1800億億（18.4×1018）倍於當前64位文件系統的數據。ZFS的設計如此超前以至於這個極限就當前現實實際可能永遠無法遇到。項目領導Bonwick曾說：「要填滿一個128位的文件系統，將耗盡地球上所有存儲設備。除非你擁有煮沸整個海洋的能量，不然你不可能將其填滿。」[1]

以下是ZFS的一些理論極限：

  • 248—任意文件系統的快照數量（2×1014）
  • 248—任何單獨文件系統的文件數（2×1014）
  • 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的文件系統數量

作為對這些數字的感性認識，假設每秒鐘創建1,000個新文件，達到ZFS文件數極限需要大約9,000年。

在辯解填滿ZFS與煮沸海洋的關係時，Bonwick寫到：

儘管我們都希望摩爾定律永遠延續，但是量子力學給定了任何物理設備上計算速率（computation rate）與信息量的理論極限[來源請求]。舉例而言，一個質量為1公斤，體積為1升的物體，每秒至多在1031位信息 上進行1051次運算[6]。一個完全的128位存儲池將包含2128個塊= 2137字節= 2140位；應此，保存這些數據位至少需要(2140位) / (1031位/公斤) = 1360億公斤的物質。

寫入時複製事務模型

ZFS採用寫入時複製事務對象模型。文件系統中的所有塊指向都包含目標塊的256位校驗和或hash值（目前有Fletcher-2（英語：Fletcher's checksum）、 Fletcher-4與SHA-2供選擇）[7]。在讀取塊時會對這些參數加以驗證。包含活動數據的塊不會被覆蓋，而是給修改過的數據分配一個新塊，任何引用此塊的元數據塊都被重新讀取、重新分配和重寫。為減少該過程的開銷，多次讀寫更新會被歸納為一個事件組，在需要同步寫入語義時會使用ZIL（目的日誌（英語：intent log））寫入緩存，而這些塊會與校驗和一同編入Merkle 樹（英語：Merkle tree）中。

利用寫入時複製使ZFS的快照和事務功能的實現變得更簡單和自然，快照功能更靈活，但嚴重碎片化問題是其缺點之一。對於通過順序寫生成的大文件，如果以後隨機的對其中的一部分進行了更改，那麼這個文件在硬盤上的物理地址就變得不再連續，未來的順序讀會變得性能比較差。

快照與克隆

當ZFS寫入新數據時，可以保留包含舊數據的塊，因而能夠維護文件系統的快照版本。ZFS快照具備一致性（快照基於單個時間點反映整個數據）。而因為組合快照的所有數據都會被儲存，且整個存儲池通常每小時會進行幾次快照，所以快照的創建速度非常快。任何未變動的數據會在文件系統及其快照之間進行共享，因此也具備空間高效性。快照本質上是只讀的，確保在創建後快照不會被修改。快照可以被整個恢復，也可以恢復快照中的某些文件或目錄。

ZFS也可以創建可寫快照（「克隆」），讓兩個獨立的文件系統共享一組塊。對克隆文件系統的修改都會創建新的數據塊以反映這些更改。但是無論存在多少個克隆，未變動的塊仍然會被共享。這是寫入時複製原則的實施方式。

動態條帶化

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

可變塊尺寸

ZFS使用可變大小的塊，最大可至128KB。現有的代碼允許管理員調整最大塊大小，這在大塊效果不好的時候有用。未來也許能做到自動調整適合工作量的塊大小。[需要引用]

ZFS的可變大小的塊與BtrFS和Ext4的extent不同。在ZFS中，在一個文件中所有數據塊的邏輯長度必須是相同的，不同文件之間的塊大小可以不同，因此ZFS可以用直接映射（direct map）的方式（同ufs/ffs/ext2/ext3）來來搜索間接塊的數據指針數組（blkptr）。BtrFS和Ext4的extent方式在同一個文件中每個數據快的大小都可以不相同，因此需要用B+ Tree或者類B Tree的方式來組織間接塊的數據。

雖然直接映射方式比B+ Tree的查找速度快，但是這種方式的缺點也非常明顯，如：元數據開銷過大、順序IO的大文件性能不好、刪除比較慢等等，因此在現代文件系統中映射方式逐漸被extent變長塊取代。

如果數據壓縮（LZJB）被啟用，可變塊大小需要被用到。如果一個數據塊可被壓縮至一個更小的數據塊，則小的數據塊將使用更少的存儲和提高吞吐量（代價是增加CPU壓縮和解壓縮的負擔）。

輕量化文件系統創建

在ZFS中，存儲池中文件系統的操作相比傳統文件系統的卷管理更加便捷。創建ZFS文件系統或者改變一個ZFS文件系統的大小接近於傳統技術中的管理目錄而非管理卷。

儲存管理

限制

ZFS的最新beta版已支持透明加密。[8]

專利爭端

NetApp指控Sun的ZFS文件系統侵犯了它WAFL的七項專利，Sun反訴NetApp侵犯了12項專利，其中包括NFS協議等。後來專利爭端以和解告終。

對其支持的操作系統

參見

參考文獻

  1. ^ 1.0 1.1 ZFS: the last word in file systems. Sun Microsystems. September 14, 2004 [2006-04-30]. （原始內容存檔於2006-04-28）. 
  2. ^ Jeff Bonwick. ZFS: The Last Word in Filesystems. Jeff Bonwick's Blog. October 31, 2005 [2006-04-30]. （原始內容存檔於2012-10-13）. 
  3. ^ Sun Celebrates Successful One-Year Anniversary of OpenSolaris. Sun Microsystems. June 20, 2006 [2007-04-21]. （原始內容存檔於2008-09-28）. 
  4. ^ Jeff Bonwick. You say zeta, I say zetta. Jeff Bonwick's Blog. 2006-05-04 [2006-09-08]. （原始內容存檔於2012-10-13）. 
  5. ^ AdvFS內部設計文件 (AdvFS Design Docs). SourceForge.net. [2011-01-25]. （原始內容存檔於2013-11-02）. 
  6. ^ Seth Lloyd, "Ultimate physical limits to computation（計算的終極物理限制） （頁面存檔備份，存於網際網路檔案館）." Nature 406, 1047-1054 (2000)]
  7. ^ ZFS On-Disk Specification (PDF). Sun Microsystems, Inc. 2006 [2017年8月14日]. （原始內容 (PDF)存檔於2008年12月30日）.  見2.4節。
  8. ^ OpenSolaris Project: ZFS on disk encryption support. OpenSolaris Project. [2006-12-13]. （原始內容存檔於2012-10-13）. 
  9. ^ 1.1 What about the licensing issue?. [November 18, 2010]. （原始內容存檔於2010-09-26）. 

外部連結

磁盤
NAS
特殊
偽
類型
特性
接口
取自「https://zh.wikipedia.org/w/index.php?title=ZFS&oldid=82319753」