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）這種機制可以累計變化，並批量運用變化，以此改進（龐大的）分類日志項列表的性能。元數據緩存也被移到了頁面緩存器的外面，頁面緩存器往往會在不合適的時間收回頁面。等等。
