XHELファイルシステムはRHEL / CentOS 6.xで壊れています-どうすればいいですか？
RHEL / CentOS（EL6）の最近のバージョンは、私が10年以上にわたって強く依存してきたXFSファイルシステムにいくつかの興味深い変更をもたらしました。昨年の夏の一部で、文書化されていないカーネルバックポートに起因するXFSスパースファイルの状況を追いかけました。EL6に移行してから、不幸なパフォーマンスの問題や一貫性のない動作をしている人もいます。 XFSは、デフォルトのext3ファイルシステムよりも安定性、スケーラビリティ、および優れたパフォーマンスの向上を提供したため、データおよび成長パーティションのデフォルトのファイルシステムでした。 2012年11月に表面化したEL6システム上のXFSに問題があります。アイドル状態でも、サーバーが異常に高いシステム負荷を示していることに気付きました。あるケースでは、アンロードされたシステムは、3 +の一定のロード平均を示します。他では、負荷に1+のバンプがありました。マウントされたXFSファイルシステムの数は、負荷増加の重大度に影響するように思われました。 システムには2つのアクティブなXFSファイルシステムがあります。影響を受けるカーネルへのアップグレード後、負荷は+2です。 深く掘り下げてみると、XFSメーリングリストxfsaildで、STAT D状態にあるプロセスの頻度が増加していることを示すスレッドがいくつか見つかりました。対応するCentOSバグトラッカーとRed Hat Bugzillaのエントリは、問題の詳細を概説し、これはパフォーマンスの問題ではないと結論付けています。2.6.32-279.14.1.el6より新しいカーネルでのシステム負荷のレポートのエラーのみ。 WTF？！？ 1回限りの状況では、負荷レポートは大した問題ではないかもしれないことを理解しています。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上にあり、同じ動作を示しています。 新しいシステムビルドキューがあり、問題を回避する必要がありました。EL6.3の2012年11月以前のリリースでカーネルバージョンをロックするか、ext4またはZFSを選択してXFSを使用しないだけで、パフォーマンスが大幅に低下します。上で実行される特定のカスタムアプリケーション用。問題のアプリケーションは、アプリケーション設計の欠陥を説明するために、XFSファイルシステム属性のいくつかに大きく依存しています。 Red Hatのペイウォール付きナレッジベースサイトの背後に行くと、次のようなエントリが表示されます。 カーネル2.6.32-279.14.1.el6をインストールした後、高い負荷平均が観察されます。平均負荷が高いのは、xfsaildが各XFS形式のデバイスでD状態になるためです。 現在、この問題の解決策はありません。現在Bugzilla＃883905で追跡されています。回避策インストールされたカーネルパッケージを2.6.32-279.14.1より前のバージョンにダウングレードします。 （RHEL 6.4のオプションではないカーネルのダウングレードを除く...） したがって、EL6.3またはEL6.4 OSリリースに対して実際の修正は予定されておらず、この問題に4か月以上かかります。EL6.5の修正案と利用可能なカーネルソースパッチがあります...しかし、私の質問は次のとおりです。 アップストリームのメンテナーが重要な機能を壊した場合、OSが提供するカーネルとパッケージから離れることはどの時点で意味がありますか？ Red Hatはこのバグを導入しました。彼らはすべき errataカーネルに修正を組み込みます。エンタープライズオペレーティングシステムを使用する利点の1つは、一貫性のある予測可能なプラットフォームターゲットを提供することです。このバグは、パッチサイクル中にすでに実稼働中のシステムを混乱させ、新しいシステムの展開に対する信頼性を低下させました。提案されたパッチのいずれかをソースコードに適用できますが、それはどれほどスケーラブルですか？OSの変更に合わせて更新を続けるには、ある程度の警戒が必要です。 ここで正しい動きは何ですか？ これはおそらく修正できるかもしれませんが、いつかは修正できません。 Red Hatエコシステムで独自のカーネルをサポートするには、独自の注意事項があります。 サポートの資格に与える影響は何ですか？ 適切なXFS機能を得るために、新しくビルドされたEL6.4サーバーの上に動作中のEL6.3カーネルを単にオーバーレイする必要がありますか？ これが正式に修正されるまで待つ必要がありますか？ これは、エンタープライズLinuxのリリースサイクルに対するコントロールの欠如について何と言っていますか？ XFSファイルシステムに長い間依存していたのは、計画/設計の間違いですか？ 編集： このパッチは、最新のCentOSPlusカーネルリリース（kernel-2.6.32-358.2.1.el6.centos.plus）に組み込まれました。私はこれをCentOSシステムでテストしていますが、これはRed Hatベースのサーバーにはあまり役立ちません。