XFS：大資料環境下Linux檔案系統的未來？

標籤：

XFS：大資料環境下Linux檔案系統的未來？ XFS開發人員Dave Chinner近日聲稱，他認為更多的使用者應當考慮XFS。XFS經常被認為是適合擁有海量資料的使用者的檔案系統，在空間分配方面的可擴充性要比ext4快“幾個數量級”。 “中繼資料驗證”意味著，讓中繼資料自我描述，保護檔案系統，防範被儲存層指錯方向的寫入。那麼，為什麼我們仍需要ext4？

AD：
WOT2015 互連網營運與開發人員大會 熱銷搶票

 

【51CTO 2月7日外電頭條】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在這方面已經做得很到位，這在將來其實是個可擴充性問題。讓數千兆MB（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開發人員會想出很好的辦法來回答這個問題，但是目前還沒有人回答得了。

XFS：大資料環境下Linux檔案系統的未來？