ファイルシステムはext4で、システムは何年も再起動されておらず、今は再起動したくありません。
かつて数百万の小さなファイル（サイズ2〜3kb）を含むフォルダがありました。これはシステムがほとんど破損する可能性があるため、あまりにも多くのファイルを生成するコードを修正し、ディレクトリ内のすべてのファイルを削除するクローンタスクを作成しました（うまくいかなかったrmため）。
最初はすべてが順調に進み、入力するとls4〜5個の残りのファイルを含む完全なリストが表示されます。
さて、翌日の入力をしてみると、システムがコマンドlsを実行するのに長い時間がかかり（数分かかり）、システム負荷を超えました。20怖がる。
基本的に数ヶ月間そうでした。 1日で初めてこれを実行すると、lsシステムが遅くなり、最終的にサブフォルダがない5つのファイルのリストが返されました。
私はこれがいくつかのext4キャッシュだと思います。いろいろなコマンドを実行してみましたが、役に立ちませんでした。
ext4がキャッシュを消去するように強制する他の方法はありますか？
システムはRAID 1モードで動作しています。 Run は、cat /proc/mdstat両方のドライブが完全に動作し、同期していることを示しています。smartctlドライブもよく戻っていると言いましたね。 hdparm は以下を返します。
hdparm -tT /dev/sda1
/dev/sda1:
Timing cached reads: 19238 MB in 2.00 seconds = 9629.50 MB/sec
Timing buffered disk reads: 316 MB in 3.01 seconds = 104.92 MB/sec
答え1
これはExtファイルシステムファミリの既知の問題です。アイテムを削除してもアイテム数が多いディレクトリのサイズが小さくならないのはなぜですか？もっと学ぶ。
この問題を解決する唯一の方法は、ディレクトリを再作成することです。まず、既存のディレクトリの名前を変更します（これを行うと、プロセスがそのディレクトリでファイルを開こうとすると問題は発生しません）。
mv brokendir repairdir/
次に、新しいディレクトリを作成します（まだ古い名前は使用しません）。
mkdir newdir
破損したディレクトリのすべての内容を新しいディレクトリに移動します。
mv repairdir/* newdir/
mv repairdir/.[!.]* newdir/
mv repairdir/..?* newdir/
（3つの個別のコマンドで構成されており、そのうちの1つが失敗した場合に何が起こるのかを正確に知ることができます。例えば移動する隠しファイルがない場合）。
新しいディレクトリのメタデータが元のディレクトリと同じであることを確認したい場合があります。特にGNU coreutilsを使用している場合は、次の方法で行うことができます（repairdir空の場合）。
cp -aT repairdir newdir
最後に、すべてを後ろに移動し、古いディレクトリを削除します。
mv newdir brokendir/
rmdir repairdir