ext3fsck時間とパーティションサイズ
私は大規模なストレージファームのセットアップを行っており、1か月のfscksの必要性を回避するために、ストレージを多数の小さなファイルシステムに分割することを計画しています（十分にバケット化されたファイルツリーがあるため、これは問題ありません） 、したがって、1/、2/、3/、4/などに個別のファイルシステムを簡単にマウントできます。
私の難しさは、ファイルシステムの「妥当な」サイズの列挙を見つけて、fsck時間を同様に「妥当な」状態に保つことです。特定のサイズの絶対時間はハードウェアに大きく依存することを十分に認識していますが、ファイルシステムサイズを変えた場合のext3 fsck時間の曲線の形状、およびその他の変数についての説明が見つからないようです（単一のディレクトリ内のファイルでいっぱいのファイルシステムは、ツリー内の数千のディレクトリのそれぞれに10個のファイルがある場合よりも時間がかかりますか？大きなファイルと小さなファイル、完全なファイルシステムと空のファイルシステムなど）。
誰かがこれについてよく研究された番号への参照を持っていますか？それができない場合、これらの問題に関する逸話は、必要に応じて、少なくとも私自身の実験を導くのに役立つはずです。
[〜＃〜] edit [〜＃〜]：明確にするために：ファイルシステムに関係なく、メタデータに問題がある場合は、チェックする必要があります。時間ベースまたはマウントベースのre-fscksが有効になっているか必要かは問題ではありません。特に、ext3に関する数値を尋ねる唯一の理由は、それが選択される可能性が最も高いファイルシステムだからです。特に高速なfsckプロセスを備えたファイルシステムをご存知の場合は、提案を受け付けていますが、堅牢なオプションである必要があります（「ファイルシステムXはfsckを必要としない」と主張し、笑われ、長々と嘲笑されます）。 。私はバックアップの必要性も認識しており、fsckを使用することはバックアップの代わりにはなりませんが、ファイルシステムを破棄し、グリッチが発生したときにバックアップから復元するだけで、fsckするのではなく、本当にそうです本当にばかげたトレードオフ。
Mathur et al。による論文 （p。29）によると、e2fsck時間は、特定の時点以降のファイルシステム上のiノードの量に比例して増加します。グラフに問題がなければ、最大1,000万iノードのファイルシステムを使用するとより効果的です。
Ext4に切り替えると、ファイルシステムが縁にロードされていない状態で役立ちます。パフォーマンスの向上（未使用とマークされたiノードをチェックしないため）は、認識できる効果がありません。
私はあなたがあなた自身のベンチマークをしなければならないだろうと思います。グーグルでのクイック検索は、ext4 fscksがext3よりもはるかに速いことを除いて、何も明らかにしませんでした。
したがって、使用するディスクサイズまで、100 GB、200GBなどのext3パーティションをいくつか作成します。次に、それらにデータを入力します。本番データに似たデータ（ディレクトリごとのファイル、ファイルサイズの分布など）を使用できる場合は、それが最適です。別のパーティションからファイルをコピーするだけでodバックアップデバイスはファイルを完全にレイアウトされ、デフラグされたディスクに配置するため、テストでは多くのディスクヘッドシーク時間が不足することに注意してください。書き込み/変更/削除の。
また、並列fscksについても考慮する必要があります。/etc/fstabの最後のいくつかのフィールドを参照してください。同じ物理ディスク上のパーティションは順番に実行する必要があります。同じコントローラー上の複数のディスクを並行して実行できますが、コントローラーに過負荷をかけたり、速度を低下させたりしないように注意してください。
http://lmgtfy.com/?q=fsck+benchmark
ext4ファイルシステムのfsckはext3よりも大幅に高速であるように見えます。ext4fsckはext3よりも10倍以上高速であるという報告もあります。
その検索からの2つの非常に興味深い記事は次のとおりです。
http://thunk.org/tytso/blog/2008/08/08/fast-ext4-fsck-times/ および- http://thunk.org/tytso/blog/2009/02/26/fast-ext4-fsck-times-revisited/