跳至內容

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）. 

外部連結

取自 "https://zh.wikipedia.org/w/index.php?title=ZFS&oldid=82319753"