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
（そして、明らかに、そのディレクトリが存在し、十分な空き容量のあるパーティションにあることを確認してください）。e2fsckはSLLOOOOWWWWWWWを実行しますが、少なくとも完了します。
もちろん、これはルートFSでは機能しませんが、スワップがある場合は、とにかくルートFSをマウントできません。
私はwombleが示唆したことを試しました。私のように、e2fsckでこの新しい機能を見たことがない場合に役立つかもしれない詳細を以下に示します。
e2fsckの「scratch_files」構成オプションは、バージョン1.40.xの期間中に利用可能になりました。（この場合、この機能を利用するには最新のDebianディストリビューションにアップグレードする必要がありました。）
推奨された「directory = / var / cache / e2fsk」オプションの他に、スクラッチファイルストレージの使用方法を微調整するためのいくつかの構成オプションがあります。「dirinfo = false」を使用しました。ファイルシステムには多数のファイルがありましたが、それほど多くのディレクトリはなかったからです。状況が逆転した場合、「icount」オプションが適切です。これらのオプションはすべて、e2fsck.confのマニュアルページに記載されています。
ところで、Ted T'soはこのスレッドでこれらのオプションについて書いています。
e2fsckの実行速度は非常に遅く、Tedの予測をはるかに上回っていました。ほとんどの場合（非常に遅い古いプロセッサで）99.9％のCPU使用率で実行されていたため、これらのデータ構造をメモリではなくディスクに保存することが減速の主な原因ではないことが示唆されます。ファイルシステムに保存されているものに関する他の何かがe2fsckを特に遅くした可能性があります。最後に、私は今のところファイルシステムのチェックを放棄しました。ファイルシステムはチェックの対象でしたが、エラーはありませんでした（私の知る限り）ので、1週間の停止が許されるより都合の良いときにチェックするように手配します。