解決策 1:
64 ビット カーネルと大容量の RAM により、fsck は高速に終了することができます。あるいは、すべての中間結果を RAM ではなくディレクトリに保存するように指示するオプションが e2fsck に追加されました。これは非常に役立ちます。 /etc/e2fsck.conf を作成 次の内容で:
[scratch_files]
directory = /var/cache/e2fsck
(そして、明らかに、ディレクトリが存在し、数 GB の十分な空き領域があるパーティション上にあることを確認してください)。 e2fsck は SLLOOOOOWWWWWWW を実行しますが、少なくとも完了します。
もちろん、これはルート FS では機能しませんが、スワップがある場合は、とにかくルート FS をマウントしていません。
解決策 2:
私は womb が提案したことを試してみました。私のように、e2fsck でこの新しい機能をまだ見たことがない場合に役立つ詳細情報を次に示します。
e2fsck の「scratch_files」設定オプションは、バージョン 1.40.x の時期に利用可能になりました。 (私たちの場合、この機能を利用するには、最新の Debian ディストリビューションにアップグレードする必要がありました。)
提案された「directory =/var/cache/e2fsk」オプションに加えて、スクラッチ ファイル ストレージの使用方法を微調整するための追加の構成オプションがいくつかあります。ファイルシステムには多数のファイルがありましたが、それほど多くのディレクトリはなかったので、「dirinfo =false」を使用しました。状況が逆の場合は、「icount」オプションが適切です。これらのオプションはすべて、e2fsck.conf の man ページに記載されています。
ところで、Ted T'so はこのスレッドでこれらのオプションについて書いています。
e2fsck の実行速度が非常に遅く、Ted の予測よりもはるかに遅いことがわかりました。ほとんどの場合、99.9% の CPU 使用率で (非常に遅い古いプロセッサで) 実行されていました。これは、これらのデータ構造をメモリではなくディスクに保存することが速度低下の主な原因ではないことを示唆しています。ファイルシステムに保存されたものに関する別の何かが、e2fsck を特に遅くした可能性があります。結局、今のところファイルシステムのチェックはやめました。ファイルシステムはチェックの予定でしたが、(私が知る限り) エラーはありませんでした。そのため、1 週間の停止を許容できる都合のよい時間にチェックするように手配します。