大きなファイルシステムでfsckを実行してメモリ不足になる
私は、512 MBのRAMを備えた古いDebian linuxボックス（etchを実行）の世話をしますが、多くの外部ストレージが接続されています。 1つのext3ファイルシステムのサイズは2.7 TB=で、fsckはそれをチェックできません。次のようなエラーでメモリ不足になるためです：
ディレクトリブロックアレイの割り当てエラー：メモリの割り当てに失敗しました e2fsck：中止されました
4 GBのスワップパーティションを追加しましたが、それでも完了しませんが、これは32ビットカーネルなので、これ以上追加しても役に立たないと思います。
64ビットカーネルで起動する以外に、fsckにチェックを完了する他の方法はありますか？
64ビットカーネルと大量のRAMを使用すると、fsckを高速で高速に終了できます。代わりに、中間結果をすべて保存するように指示するe2fsckのオプションがRAMの代わりにディレクトリを作成すると、非常に役立ちます。次の内容で/etc/e2fsck.confを作成します。
[scratch_files]
directory = /var/cache/e2fsck
（そして、明らかに、そのディレクトリが存在し、空き容量が数GB多いパーティションにあることを確認してください）。 e2fsckはSLLOOOOWWWWWWWを実行しますが、少なくとも完了します。
もちろん、これはルートFSでは機能しませんが、スワップがある場合は、ルートFSとにかくマウントすることはできません。
ウォンブルが提案したことを試してしまいました。私のように、e2fsckでこの新機能を以前に見たことがない場合に役立つと思われる詳細がいくつかあります。
E2fsckの "scratch_files"設定オプションは、バージョン1.40.xの時期に利用可能になった。 （私たちの場合、この機能を使用するには、最新のDebianディストリビューションにアップグレードする必要がありました。）
提案された「directory =/var/cache/e2fsk」オプションの他に、スクラッチファイルストレージの使用方法を微調整するための設定オプションがいくつかあります。 「dirinfo = false」を使用しました。ファイルシステムには多数のファイルがありましたが、それほど多くのディレクトリはありませんでした。状況が逆転した場合は、「icount」オプションが適切です。これらのオプションはすべて、e2fsck.confのマニュアルページに記載されています。
ところで、Ted T'soはこれらのオプションについて this thread で書きました。
私はe2fsckが非常に遅い速度で動作していることを発見しました。これは、Tedが予測したよりもはるかに高速です。ほとんどの場合、CPU使用率が99.9％で実行されていました（非常に遅い古いプロセッサ上）。これは、これらのデータ構造をメモリではなくディスクに保存することがスローダウンの主な原因ではなかったことを示しています。ファイルシステムに格納されたものに関する他の何かがe2fsckを特に遅くした可能性があります。結局、私は今のところファイルシステムのチェックを断念しました。ファイルシステムはチェックの予定でしたが、（私が知る限り）エラーがなかったので、1週間の停止が許容されるより都合のよい時間にチェックするように手配します。