XFSファイルシステムが突然より多くのスペースとスパースファイルでいっぱいになるのはなぜですか？

XFSファイルシステムをさまざまなLinuxサーバーでほぼ10年間データ/成長パーティションとして実行しています。

バージョン6.2以降を実行している最近のCentOS / RHELサーバーで奇妙な現象に気づきました。

EL6.0およびEL6.1から新しいOSリビジョンに移行した後、安定したファイルシステムの使用は非常に変化しやすくなりました。最初にEL6.2 +でインストールされたシステムは同じ動作を示します。XFSパーティションのディスク使用率の急激な変動を示します（下のグラフの青い線を参照）。

前後。6.1から6.2へのアップグレードは土曜日に行われました。

同じシステムの前四半期のディスク使用量グラフ。先週の変動を示しています。

大きなファイルと暴走プロセス（ログファイル、おそらく？）のファイルシステムをチェックし始めました。私の最大のファイルがduとから異なる値を報告していることを発見しましたls。スイッチduありと--apparent-sizeスイッチなしで実行すると、違いがわかります。

# du -skh SOD0005.TXT
29G     SOD0005.TXT

# du -skh --apparent-size SOD0005.TXT
21G     SOD0005.TXT

ファイルシステム全体でncduユーティリティを使用して簡単に確認すると、次の結果が得られました。

Total disk usage: 436.8GiB  Apparent size: 365.2GiB  Items: 863258

ファイルシステムにはスパースファイルがいっぱいで、以前のバージョンのOS /カーネルと比較して70GB近くのスペースが失われています！

Red Hat Bugzillaに目を通し、ログを変更して、XFSに関する同じ動作の報告または新しい発表があるかどうかを確認しました。

N。

アップグレード中にカーネルバージョン2.6.32-131.17.1.el6から2.6.32-220.23.1.el6に移行しました。マイナーバージョン番号に変更はありません。

filefragツールでファイルの断片化をチェックしました。XFSパーティション上の最大のファイルには、数千のエクステントがありました。xfs_fsr -v低速のアクティビティ中にオンラインデフラグを実行すると、ディスク使用量が一時的に削減されました（上の最初のグラフの水曜日を参照）。ただし、大量のシステムアクティビティが再開されるとすぐに使用量が増加しました。

ここで何が起きてるの？

この問題は、2010年12月からのXFSソースツリーへのコミットに関する議論にまでさかのぼります。このパッチは、カーネル2.6.38で導入されました（明らかに、後に人気のあるLinuxディストリビューションカーネルにバックポートされました）。

観測されたディスク使用量の変動は、新しい機能の結果です。XFS動的投機的EOF事前割り当て。

これは、ファイルサイズの増加に応じて投機的にスペースを割り当てることで、ストリーミング書き込み中のファイルの断片化を減らす動きです。ファイルごとに事前に割り当てられるスペースの量は動的であり、主にファイルシステムで使用可能な空きスペースの関数です（スペースが完全に不足するのを防ぐため）。

このスケジュールに従います。

freespace       max prealloc size
  >5%             full extent (8GB)
  4-5%             2GB (8GB >> 2)
  3-4%             1GB (8GB >> 3)
  2-3%           512MB (8GB >> 4)
  1-2%           256MB (8GB >> 5)
  <1%            128MB (8GB >> 6)

これは、私が扱う大規模に断片化されたファイルの一部に役立つ可能性があるため、ファイルシステムへの興味深い追加です。

追加のスペースは、次の方法でページキャッシュ、デントリ、およびiノードを解放することで一時的に再利用できます。

sync; echo 3 > /proc/sys/vm/drop_caches

allocsizeファイルシステムのマウント中に値を定義することにより、この機能を完全に無効にすることができます。XFSのデフォルトはallocsize=64kです。

この変更の影響は、おそらく監視/しきい値システム（これが私がそれを捕らえた方法です）によって感じられますが、データベースシステムにも影響を与え、シンプロビジョニングされた仮想マシンとストレージアレイに予測不能または望ましくない結果を引き起こす可能性があります（それらは使用します）予想以上のスペース）。

全体として、配布レベルで、またはXFSメーリングリストの監視でさえ、ファイルシステムの変更の明確なアナウンスがなかったため、私は油断しました。

編集：
この機能を備えたXFSボリュームのパフォーマンスが大幅に改善されました。以前に最大50％の断片化を表示していたボリュームで、一貫した<1％の断片化が見られます。書き込みパフォーマンスはグローバルに向上しています！

同じデータセットからの統計。レガシーXFSとEL6.3のバージョンを比較します。

古い：

# xfs_db -r -c frag /dev/cciss/c0d0p9
actual 1874760, ideal 1256876, fragmentation factor 32.96%

新着：

# xfs_db -r -c frag /dev/sdb1
actual 1201423, ideal 1190967, fragmentation factor 0.87%