閱讀151 返回首頁    go 搜狐 go 中電雲集


簡單介紹xfs文件係統(轉載)

XFS 最初是由 Silicon Graphics,Inc. 於 90 年代初開發的。那時,SGI 發現他們的現有文件係統(existing filesystem,EFS)正在迅速變得不適應當時激烈的計算競爭。為解決這個問題,SGI 決定設計一種全新的高性能 64 位文件係統,而不是試圖調整 EFS在先天設計上的某些缺陷。因此,XFS 誕生了,並於 1994 年隨 IRIX 5.3 的發布而應用於計算。

XFS 是 Silicon Graphics,Inc. 於 90 年代初開發的。它至今仍作為 SGI 基於 IRIX 的產品(從工作站到超級計算機)的底層文件係統來使用。現在,XFS 也可以用於 Linux。XFS 的 Linux 版的到來是激動人心的,首先因為它為 Linux 社區提供了一種健壯的、優秀的以及功能豐富的文件係統,並且這種文件係統所具有的可伸縮性能夠滿足最苛刻的存儲需求。   主要特性包括: 數據完全性   采用XFS文件係統,當意想不到的宕機發生後,首先,由於文件係統開啟了日誌功能,所以你磁盤上的文件不再會意外宕機而遭到破壞了。不論目前文件係統上存儲的文件與數據有多少,文件係統都可以根據所記錄的日誌在很短的時間內迅速恢複磁盤文件內容。   傳輸特性   XFS文件係統采用優化算法,日誌記錄對整體文件操作影響非常小。XFS查詢與分配存儲空間非常快。xfs文件係統能連續提供快速的反應時間。筆者曾經對XFS、JFS、Ext3、ReiserFS文件係統進行過測試,XFS文件文件係統的性能表現相當出眾。   可擴展性   XFS 是一個全64-bit的文件係統,它可以支持上百萬T字節的存儲空間。對特大文件及小尺寸文件的支持都表現出眾,支持特大數量的目錄。最大可支持的文件大小為263 = 9 x 1018 = 9 exabytes,最大文件係統尺寸為18 exabytes。   XFS使用高的表結構(B+樹),保證了文件係統可以快速搜索與快速空間分配。XFS能夠持續提供高速操作,文件係統的性能不受目錄中目錄及文件數量的限製。   傳輸帶寬   XFS 能以接近裸設備I/O的性能存儲數據。在單個文件係統的測試中,其吞吐量最高可達7GB每秒,對單個文件的讀寫操作,其吞吐量可達4GB每秒。   XFS 設計: 分配組(allocation groups)   當創建 XFS 文件係統時,底層塊設備被分割成八個或更多個大小相等的線性區域(region)。您可以將它們想象成“塊”(chunk)或者“線性範圍(range)”,但是在 XFS 術語中,每個區域稱為一個“分配組”。分配組是唯一的,因為每個分配組管理自己的索引節點(inode)和空閑空間,實際上,是將這些分配組轉化為一種文件子係統,這些子係統正確地透明存在於 XFS 文件係統內。

xfs內部結構部分介紹:

1 XFS INODE number:變長的位數表示,三部分組成:起始塊組號+起始塊號+塊內INODE號。起始塊號與塊內INODE號的位長由SUPERBLOCK中參數指定。   2 XFS EXT number:變長的位數表示,對於32位係統版本,首先用4個4字節表示EXT 編號,EXT編號由兩部分組成:起始位置和大小。EXT編號的起始位置為L1(0-32)連接L2(0-32)連接L3(31-21)構成中間值(暫定為TEMP)然後TEMP又由兩部分組成:塊組號與塊組內部塊號,結構為後agblklog位表示內部塊號,其餘高位表示塊組號。   分配組與可伸縮性   那麼,XFS 到底為什麼要有分配組呢?主要原因是,XFS 使用分配組,以便能有效地處理並行 IO。因為,每個分配組實際上是一個獨立實體,所以內核可以 同時與多個分配組交互。如果不使用分配組,XFS 文件係統代碼可能成為一種性能瓶頸,迫使大量需求 IO 的進程“排隊”來使索引節點進行修改或執行其它種類的元數據密集操作。多虧了分配組,XFS 代碼將允許多個線程和進程持續以並行方式運行,即使它們中的許多線程和進程正在同一文件係統上執行大規模 IO 操作。因此,將 XFS 與某些高端硬件相結合,您將獲得高端性能而不會使文件係統成為瓶頸。分配組還有助於在多處理器係統上優化並行 IO 性能,因為可以同時有多個元數據更新處於“在傳輸中”。   B+ 樹無處不在   分配組在內部使用高效的 B+ 樹來跟蹤主要數據,譬如空閑空間的範圍和索引節點。實際上,每個分配組使用 兩棵 B+ 樹來跟蹤空閑空間;一棵樹按空閑空間的大小排序來存儲空閑空間的範圍,另一棵樹按塊設備上起始物理位置的排序來存儲這些區域。XFS 擅長於迅速發現空閑空間區域,這種能力對於最大化寫性能很關鍵。   當對索引節點進行管理時,XFS 也是很有效的。每個分配組在需要時以 64 個索引節點為一組來分配它們。每個分配組通過使用 B+ 樹來跟蹤自己的索引節點,該 B+ 樹記錄著特定索引節點號在磁盤上的位置。您會發現 XFS 之所以盡可能多地使用 B+ 樹,原因在於 B+ 樹的優越性能和極大的可擴展性。   日誌記錄 當然,XFS 也是一種日誌記錄文件係統,它允許意外重新引導後的快速恢複。象 ReiserFS 一樣,XFS 使用邏輯日誌;即,它不象 ext3 那樣將文字文件係統塊記錄到日誌,而是使用一種高效的磁盤格式來記錄元數據的變動。就 XFS 而言,邏輯日誌記錄是很適合的;在高端硬件上,日誌經常是整個文件係統中爭用最多的資源。通過使用節省空間的邏輯日誌記錄,可以將對日誌的爭用降至最小。另外,XFS 允許將日誌存儲在另一個塊設備上,例如,另一個磁盤上的一個分區。這個特性很有用,它進一步改進了 XFS 文件係統的性能。   象 ReiserFS 一樣,XFS 隻對元數據進行日誌記錄,並且在寫元數據之前,XFS 不采取任何專門的預防措施來確保將數據保存到磁盤。這意味著,使用 XFS(就象使用 ReiserFS)時,如果發生意外的重新引導,則最近修改的數據有可能丟失。然而,XFS 日誌有兩個特性使得這個問題不象使用 ReiserFS 時那麼常見。   使用 ReiserFS 時,意外重新引導可能導致最近修改的文件中包含先前刪除文件的部分內容。除了數據丟失這個顯而易見的問題以外,理論上,這還可能引起安全性威脅。相反,當 XFS 日誌係統重新啟動時,XFS 確保任何未寫入的數據塊在重新引導時 置零。因此,丟失塊由空字節來填充,這消除了安全性漏洞 ― 這是一種好得多的方法。   現在,關於數據丟失問題本身,該怎麼辦呢?通常,使用 XFS 時,該問題被最小化了,原因在於以下事實:XFS 通常比 ReiserFS 更頻繁地將暫掛元數據更新寫到磁盤,尤其是在磁盤高頻率活動期間。因此,如果發生死鎖,那麼,最近元數據修改的丟失,通常比使用 ReiserFS 時要少。當然,這不能徹底解決不及時寫數據塊的問題,但是,更頻繁地寫元數據也確實促進了更頻繁地寫數據。   延遲分配 研究一下 延遲分配這個 XFS 獨有的特性,然後我們將結束關於 XFS 的技術概述。正如您可能知道的,術語 分配(allocation)是指:查找空閑空間區域並用於存儲新數據的過程。   XFS 通過將分配過程分成兩個步驟來處理。首先,當 XFS 接收到要寫入的新數據時,它在 RAM 中記錄暫掛事務,並隻在底層文件係統上 保留適當空間。然而,盡管 XFS 為新數據保留了空間,但 它卻沒有決定將什麼文件係統塊用於存儲數據,至少現在還沒決定。XFS 進行拖延,將這個決定延遲到最後可能的時刻,即直到該數據真正寫到磁盤之前作出。   通過延遲分配,XFS 贏得了許多機會來優化寫性能。到了要將數據寫到磁盤的時候,XFS 能夠以這種優化文件係統性能的方式,智能地分配空閑空間。尤其是,如果要將一批新數據添加到單一文件,XFS 可以在磁盤上分配一個 單一、相鄰區域來儲存這些數據。如果 XFS 沒有延遲它的分配決定,那麼,它也許已經不知不覺地將數據寫到了多個非相鄰塊中,從而顯著地降低了寫性能。但是,因為 XFS 延遲了它的分配決定,所以,它能夠一下子寫完數據,從而提高了寫性能,並減少了整個文件係統的碎片。   在性能上,延遲分配還有另一個優點。在要創建許多“短命的”臨時文件的情況下,XFS 可能根本不需要將這些文件全部寫到磁盤。因為從未給這些文件分配任何塊,所以,也就不必釋放任何塊,甚至根本沒有觸及底層文件係統元數據。

最後更新:2017-01-04 22:34:37

  上一篇:go 數據庫標準常用SQL語句
  下一篇:go hyper-v中linux更改時間問題