XFS：大數據環境下Linux文件系統的未來？

　　來源：51CTO

　　Linux有好多種件系統，但往往最受關注的是其中兩種：ext4和btrfs。XFS開發者Dave Chinner近日聲稱，他認為更多的用戶應當考慮XFS。他談到了為了解決XFS中最嚴重的可擴展性問題所做的工作，還談到了他認為將來的發展走向。如果他說的一點都沒錯，接下來幾年我們在XFS方面有望看到更多的動靜。

　　XFS經常被認為是適合擁有海量數據的用戶的文件系統。Dave表示，XFS非常適合扮演這個角色；它對許多工作負載而言向來表現不俗。以前往往問題出在元數據寫入方面；對生成大量元數據寫入操作的工作負載缺少有力的支持歷來是該文件系統的薄弱環節。簡而言之，元數據寫入速度很慢，擴展性欠佳，甚至只能適用於單個處理器。

　　速度到底有多慢？Dave製作了幾張幻燈片，顯示XFS與ext4相比的fs-mark結果。哪怕在單個處理器上，XFS的表現也要差得多（速度只有ext4的一半）；如果線程數量多達8個，情況完全變得更糟；但線程數量超過8個后，ext4也遇到了瓶頸，速度慢下來。就元數據頻繁變化的輸入/輸出密集型工作負載（解開tarball文件就是個例子）而言，Dave表示ext4的速度可能比XFS快20倍至50倍。速度這麼慢足以表明XFS確實存在嚴重問題。

　　延遲的日誌

　　結果表明問題其實出在日誌的輸入/輸出上。針對元數據的變化，XFS會生成大量的日誌流量。在最糟糕的情況下，幾乎所有的實際輸入/輸出流量都用於日誌——而不是用於用戶試圖想要寫入的數據。多年來人們試圖採用多種辦法來解決這個問題，比如對演算法進行重大改變，另外進行許多重大的優化和調整。不需要的一點是任何一種磁碟上格式變化，不過這在將來可能由於其他原因而在籌劃之中。

　　元數據密集型的工作負載最後可能會在很短的時間內多次改變同一個目錄塊；那些改變每一次都會生成一個記錄，記錄必須寫入到日誌中。這正是導致巨大日誌流量的根源。解決這個問題的辦法從概念上來說很簡單：延遲日誌更新，並且將針對同一目錄塊的變更合併到一個條目中。這些年來，以一種可擴展的方式實際落實這個概念頗費周折，但是現在取得了進展；延遲的日誌（delayed logging）將是3.3內核中唯一得到支持的XFS日誌模式。

　　實際的延遲日誌技術主要由ext3文件系統借鑒而來。由於這種演算法已知切實可行，證明它同樣適用於XFS所需的時間則短得多。除了性能上的優點外，這一變化最終促使代碼數量減少。有誰想詳細了解其工作原理，應該會在內核文檔樹中的filesystems/xfs-delayed-logging.txt找到所需內容。

　　延遲日誌是一大變化，但絕不是唯一的變化。日誌空間預留快速路徑是XFS中非常熱門的路徑；現在它是無鎖的，不過慢速路徑現階段仍需要全局鎖。非同步元數據寫回代碼形成了非常分散的輸入/輸出，結果大幅降低了性能。現在，元數據寫回在寫出之前已被延遲和分類。用Dave的話來說，這意味著文件系統在做輸入/輸出調度程序的工作。但是輸入/輸出調度程序處理的請求序列通常限制在128個條目，而XFS的延遲元數據寫回序列可以有數千個條目，所以有必要在輸入/輸出提交之前在文件系統中完成分類操作。「活動日誌項」（Active log item）這種機制可以累計變化，並批量運用變化，以此改進（龐大的）分類日誌項列表的性能。元數據緩存也被移到了頁面緩存器的外面，頁面緩存器往往會在不合適的時間收回頁面。等等。

　　諸文件系統相比如何？

　　那麼，現在XFS的擴展性如何？如果是一兩個線程，XFS的速度仍比ext4慢一點，但是它可以線性擴展，支持多達8個線程，而ext4的情況比較糟，btrfs的情況要糟得多。對XFS來說擴展性方面的局限性如今出現在虛擬文件系統層核心中的鎖定上，根本不是出現在針對特定文件系統的代碼上。現在即使對一個線程來說，目錄遍歷速度也更快，對8個線程來說，速度快得多。他表示，這些並不是btrfs開發人員可能展示給人的那種結果。

　　現在空間分配方面的可擴展性要比ext4快「幾個數量級」。這是由於3.2內核中添加了「bigalloc」特性而引起的變化，如果使用了足夠大的塊，這項特性可以將ext4在空間分配方面的可擴展性提高兩個數量級。遺憾的是，該特性還將小文件的空間使用量增加了同樣數量，以至於需要160GB來存放內核樹。bigalloc並不是很適合ext4的另外一些選項，而且需要管理員回答覆雜的配置問題；在創建文件系統時，管理員必須考慮文件系統在整個使用壽命期間將如何使用。Dave表示，ext4存在架構方面的不足——尤其是使用點陣圖來用於跟蹤空間，這是上世紀80年代的文件系統存在的典型問題。它根本無法擴展，成為真正超大的文件系統。

　　btrfs中的空間分配甚至比ext4還要來得慢。Dave表示，問題主要出在閑置空間緩存的走查，目前這是處理器密集型的操作。這不是btrfs中的架構問題，所以它應該有望得到解決，但需要做一番優化工作。

　　Linux文件系統的未來

　　這方面有何進展？現階段，XFS中的元數據性能和可擴展性可以被認為是已得到解決的問題。現在性能瓶頸出現在虛擬文件系統（VFS）層，所以需要在這方面開展下一輪工作。但是未來面臨的一大挑戰在於可靠性方面；這可能需要XFS文件系統作出一些相當大的變化。

　　可靠性不僅僅是不丟失數據這麼簡單——但願XFS在這方面已經做得很到位，這在將來其實是個可擴展性問題。讓數千兆兆位元組（PT）的文件系統下線、運行一款文件系統檢查和修復工具，這根本不切實際；將來，這項工作其實需要在線進行。這就需要把成熟可靠的故障檢測機制融入到文件系統當中，以便可以實時驗證元數據正確無誤。其他一些文件系統也在實施驗證數據的機制，但是這似乎超出了XFS的範圍。Dave表示，數據驗證工作最好是在存儲陣列層面或應用程序層面完成。

　　「元數據驗證」意味著，讓元數據自我描述，保護文件系統，防範被存儲層指錯方向的寫入。添加校驗和技術還不夠——核驗和只能證明現有的是被寫入的。以適當方式自我描述的元數據能夠檢測寫入到錯誤地方的塊，並且幫助重新組裝完全壞掉的文件系統。它還能防止「"reiserfs問題」，即文件系統的修復工具被過時的元數據或存儲在待修復的文件系統中的文件系統映像裡面的元數據搞糊塗。

　　讓元數據可以自我描述需要作出許多變化。每個元數據塊將包含文件系統的UUID；每個塊中還有塊和索引節點（inode）的編號，那樣文件系統就能驗證元數據來自預期的地方。將來會有檢驗和機制，用來檢測受到損壞的元數據塊，還會有所有者標識符，用來將元數據與歸屬的索引節點或目錄關聯起來。反向映射分配樹將讓文件系統可以迅速確認任何某個塊屬於哪個文件。

　　不用說，目前的XFS磁碟上格式並不提供存儲所有這些額外數據的機制。這意味著磁碟上格式會有變化。據Dave聲稱，不打算提供任何形式的向前或向後格式兼容；格式變化將是真正重大的變化。開展這項工作是為了便於完全自由地設計一種長期服務於XFS用戶的新格式。雖然正在改變格式來添加上述的可靠性功能，但是開發人員也會為目錄結構中的d_type、NFSv4版本計數器、索引節點創建時間以及可能更多對象添加空間。最大的目錄大小（目前只有區區32GB）也會得到提高。

　　這一切將帶來許多優點：主動檢測文件系統受損情況、定位和更換缺乏聯繫的塊以及更好的在線文件系統修復。Dave表示，這意味著在將來很長一段時間，對Linux環境下的大數據應用程序而言，XFS仍將是最出色的文件系統。

　　從btrfs的角度來看，這一切又意味著什麼呢？Dave表示，btrfs顯然不是針對處理元數據密集型工作負載的文件系統而優化；有一些嚴重的可擴展性問題成為了攔路虎。對於處於早期開發階段的一款文件系統來說，這完全在意料之中。其中一些問題需要藉以時日才能克服，但可能存在這種情況：其中一些問題可能無法得到解決。另一方面，btrfs中的可靠性功能開發得很完善，這款文件系統完全能夠提供在接下來幾年預期的存儲功能。

　　而ext4存在架構可擴展性問題。據Dave的結果顯示，它不再是速度最快的文件系統。有幾個方案可用來改進可靠性，其磁碟上格式顯露了老態。ext4支持在不遠將來的存儲需求有難度。

　　考慮到這點，Dave在最後拋出了一個問題。由於其豐富功能，btrfs不日將取代ext4，成為許多Linux發行版中的默認文件系統。與此同時，ext4在處理大多數工作負載方面性能不如XFS，包括它在傳統上表現更強勁的應用領域。一些可擴展性問題甚至出現在了更小的伺服器系統上。「匯聚半完成的項目」並不總是能取得很好的效果；Dave表示，ext4並不如人們想象的那麼穩定或久經測試。於是他問道：為什麼我們仍需要ext4？

　　有人可能認為，ext4開發人員會想出很好的辦法來回答這個問題，但是目前還沒有人回答得了。

Tags: