Private Cloud基盤におけるEXT系ファイルシステムの非推奨
基本的にファイルシステムに「ext2/3/4」を使う事は非推奨です。
CentOS7以降では「XFS」が標準で使われており、ファイルフォーマットが選択可能なOSでは、XFSやbtrfs、ZFSなどEXT以外のもの使う方が良いでしょう。
ext系ファイルシステムを使うべきではない理由
3-Tier型でHigh Response Private Cloudを利用をしたり、あるいはストレージを伴うライブマイグレーションを発生させるとき、仮想OSからみると、ストレージは一定の遅延が発生します。これは、Private Cloud基盤やStorageの全体の負荷だけでなく、仮想OSからのストレージの書き換え量にも影響し、やむを得ないことです。
このため、一般的にはファイルシステムの処理として、一定の遅延が発生したとしても、OSはそのまま「待ち」状態に入ることで、たとえストレージシステムに遅延が発生したとしても、動作が再び健全になったら動き始めるようになります。(ただし上位のアプリケーション層のタイムアウトの最小値までには健全に戻らなくてはなりません)
一方、ext系ファイルシステムは、ストレージ遅延がある程度発生した場合、これを障害と見なし、リードオンリー(書き込みできないモード)でストレージを再マウント(ro-remount)します。ro-remountになった場合、システムはその状態のまましばらく動作し、再起動するまで通常のマウント状態には戻りません(rw,remountは不可能)。問題は、ro-remountになったことが気がつかないケースで、Linuxシステムはディスクキャッシュ層が厚く、数時間から長いときには数日にわたり動き続けることです。結果、リードオンリーのためデータもログも記録されず、ある時点でサーバーはこれ以上動作できなくなりダウンします。大抵は再起動により復帰しますが、リードオンリーになった時点から、データも記録されず、ログを見ても停止しているように見えます。
この問題は、extファイルシステムを使う限り、マウントオプションを調整しても、本質的には回避することはできません。
errors=continue
マウントオプションにerrors=continueを設定する場合、基本的な要件においては「待ち」続けます。したがって、いくつかのケースでro-remountの動きが緩和されることとなります。しかし、クリティカルなジャーナルエラー、深刻なメタデータ欠損、或いはディスクI/Oが連続して失敗する場合にはro-remountモードとなります。通常、「待ち」を行うとき、定期的にI/Oを試みることで、待ち続けるかを決めますが、リトライを発生させてもI/Oが正常に完了しない場合、継続的なエラーカウントとして記憶され、エラーが積み重なることとなります。この結果、jbd2_journal_commit_transactionなどの関数内で、ジャーナルのコミット失敗が深刻であると判定され、ro-remountのモードとなります。従ってこの設定は若干の緩和策にしかなりません。
errors=panic
マウントオプションにerrors=panicを指定したとき、ファイルシステムにエラーが発生すると、システム全体を停止してカーネルパニックを起こします。この場合、システムは完全に停止するため、監視などで異常を検出しやすくなり、問題にすぐ気がつくことができます。ただし、ストレージの応答劣化の深刻度に応じて、意図しないpanicになる可能性もありますし、ディスクに対するエラーとなるため、クラッシュダンプも取得できません。