XFS 文件系統在 RHEL/CentOS 6.x 中損壞 - 我該怎麼辦？
最新版本的 RHEL/CentOS (EL6) 為我十多年來一直非常依賴的XFS 文件系統帶來了一些有趣的變化。去年夏天，我花了一部分時間追查由文件不完整的核心反向移植導致的XFS 稀疏文件情況。自從遷移到 EL6 後，其他人遇到了不幸的性能問題或不一致的行為。
XFS 是我用於數據和增長分區的預設文件系統，因為與預設的 ext3 文件系統相比，它提供了穩定性、可擴展性和良好的性能提升。
2012 年 11 月出現的 EL6 系統上的 XFS 問題。我注意到我的伺服器顯示異常高的系統負載，即使在空閒時也是如此。在一種情況下，空載系統會顯示 3+ 的恆定負載平均值。在其他情況下，負載增加了 1+。安裝的 XFS 文件系統的數量似乎會影響負載增加的嚴重程度。
系統有兩個活動的 XFS 文件系統。升級到受影響的核心後負載為 +2。
深入探勘後，我在XFS 郵件列表
xfsaild中發現了一些執行緒，這些執行緒表明程序處於STAT D狀態的頻率有所增加。相應的CentOS Bug Tracker和Red Hat Bugzilla條目概述了問題的細節，並得出結論認為這不是性能問題；只有在2.6.32-279.14.1.el6更新的核心中報告系統負載的錯誤。怎麼回事？！？
在一次性情況下，我知道負載報告可能沒什麼大不了的。嘗試使用您的 NMS 和成百上千台伺服器來管理它！這是 2012 年11 月在 EL6.3 下的核心2.6.32-279.14.1.el6中發現的。核心2.6.32-279.19.1.el6和2.6.32-279.22.1.el6在隨後的幾個月（2012 年 12 月和 2013 年 2 月）發布，此行為沒有改變。自從發現此問題以來，甚至還有一個新的作業系統次要版本。EL6.4 已發布，現在位於核心2.6.32-358.2.1.el6上，表現出相同的行為。
我有一個新的系統建構隊列並且不得不解決這個問題，要麼在 2012 年 11 月之前的 EL6.3 版本中鎖定核心版本，要麼只是不使用 XFS，選擇ext4或ZFS，這會導致嚴重的性能損失對於在上面執行的特定自定義應用程序。有問題的應用程序嚴重依賴某些 XFS 文件系統屬性來解決應用程序設計中的缺陷。
在 Red Hat 的付費知識庫網站後面，出現一個條目，說明：
安裝核心 2.6.32-279.14.1.el6 後觀察到高負載平均值。高負載平均值是由於 xfsaild 進入每個 XFS 格式化設備的 D 狀態引起的。
目前沒有解決此問題的方法。目前正在通過 Bugzilla #883905 對其進行跟踪。解決方法 將安裝的核心包降級到低於 2.6.32-279.14.1 的版本。
（除了降級核心不是 RHEL 6.4 上的選項…）
所以我們在這個問題上已經 4 個多月了，沒有為 EL6.3 或 EL6.4 作業系統版本計劃真正的修復。有一個針對 EL6.5 的建議修復程序和一個可用的核心源更新檔……但我的問題是：
當上游維護者破壞了一個重要特性時，什麼時候離開作業系統提供的核心和包才有意義？
Red Hat 引入了這個錯誤。他們應該將修復程序合併到勘誤表核心中。使用企業作業系統的優勢之一是它們提供了一致且可預測的平台目標。這個錯誤在更新檔週期中破壞了已經在生產中的系統，並降低了部署新系統的信心。雖然我可以將建議的更新檔之一應用於原始碼，但它的可擴展性如何？隨著作業系統的變化，需要保持警惕才能保持更新。
這裡的正確做法是什麼？
- 我們知道這可能會解決，但不是什麼時候。
- 在紅帽生態系統中支持您自己的核心有其自身的一套注意事項。
- 對支持資格有什麼影響？
- 我是否應該在新建的 EL6.4 伺服器之上覆蓋一個工作的 EL6.3 核心以獲得適當的 XFS 功能？
- 我應該等到正式解決這個問題嗎？
- 這說明我們對企業 Linux 發布週期缺乏控制是什麼？
- 長期依賴 XFS 文件系統是一個規劃/設計錯誤嗎？
編輯：
這個更新檔被納入最新的CentOSPlus核心版本（kernel-2.6.32-358.2.1.el6.centos.plus）。我正在我的 CentOS 系統上對此進行測試，但這對基於 Red Hat 的伺服器沒有多大幫助。
當上游維護者破壞了一個重要特性時，什麼時候離開作業系統提供的核心和包才有意義？
“在供應商的核心或軟體包嚴重損壞以致影響您的業務時”是我的一般回答（巧合的是，這也是我說開始尋找脫離供應商關係的方法的意義所在） .
基本上正如您和其他人所說，RedHat 似乎不想在他們的分佈式核心中修補這個（無論出於何種原因）。這幾乎使您不得不滾動自己的核心（自己更新更新檔，維護自己的軟體包並使用 Puppet 或類似工具將其安裝在您的系統上，或者執行 Yum 或其他任何軟體的軟體包伺服器）今天使用可以參考），或者拿著你的彈珠回家。
是的，我知道帶上你的彈珠回家通常是一個昂貴的提議——切換作業系統供應商是一個巨大的痛苦，尤其是在 Linux 世界中，從管理的角度來看，口味完全不同。
其他選項，比如完全使用 CentOS 也沒有吸引力（因為你失去了支持，而且你仍然得到基本上由其他人建構的 RedHat 程式碼，所以你仍然有這個錯誤）。
不幸的是，除非有足夠多的人（即“大公司”）拿出他們的彈珠回家，否則供應商不會太在意通過發送錯誤程式碼而不修復它來搞砸人們。