☰

巨大なディレクトリ。中のファイルではなくディレクトリ自体

tag-icon • tag-icon linux filesystems ext3
巨大なディレクトリ。中のファイルではなくディレクトリ自体

過去 15 時間、centos サーバーからディレクトリを削除しようとしていますrm -Rf /root/FFDCが、非常に困難です。システムがハングするためディレクトリの一覧表示ができません (ファイルが多すぎるためでしょうか)。ただし、ディレクトリのサイズが通常の 4096 バイトではなく 488 MB であることがわかります。

[root@IS-11034 ~]# ls -al
total 11760008
drwxr-x--- 31 root root        4096 Aug 10 18:28 .
drwxr-xr-x 25 root root        4096 Aug 10 16:50 ..
drwxr-xr-x  2 root root   488701952 Aug 11 12:20 FFDC

inode をチェックしましたが、すべて正常のようです。top をチェックしたところ、rm15 時間経過後も CPU 使用率は 0.7% のままです。ファイルシステムの種類は ext3 です。

バックアップとフォーマット以外に、今どこに行けばいいのか全く分かりません。

答え1

さらにls -1f /root/FFDC遅いですか? -1f を使用すると、出力はソートされず、ファイルの詳細は省略されます。

上記の ls が高速に実行される場合、次のようなものの方find /root/FFDC | xargs rm -vfが高速になるでしょうか? 通常は、スキップできる可能性のあるrm -rfあらゆる種類の再帰を実行する可能性があります。または、スキップできないこともあります。find

ファイルシステムは次のようにマウントされていますか？同期オプションですか？そうであれば、書き込み/削除のパフォーマンスは、非同期疑問がある場合は、試してみるとよいでしょうmount -o remount,async /(または、mount -o remount,async /rootそれが別のファイルシステムである場合)。

答え2

ファイルシステムをアンマウントし、e2fsck を実行してファイルシステムのエラーをチェックすることを検討しましたか? バックアップ、フォーマット、復元の前にこれを試してください。

答え3

ファイルシステム上で fsck を実行すると、問題は解決します。これは通常、ディレクトリに以前は多くのファイルが含まれていたが、現在は含まれていない場合に発生します。ディレクトリのサイズが非常に大きいため、パフォーマンスが低下します。

答え4

ディレクトリが再編成されるかどうかはわかりませんが、フラグ ( で説明されているように)fsck(8)を試してみるとよいでしょう。再編成されず、そのディレクトリに実際に何百万ものファイルが含まれていない場合は、次のような方法で適切なサイズのディレクトリを作成できます。-De2fsck(8)

cd /root mv FFDC FFCD-old mkdir FFCD # FFDC の権限を調整します mv FFDC-old/* FFDC # FFDC-old 内の .xxx ファイル/ディレクトリを確認/移動します rmdir FFCD-old

少なくともいくつかのbashバージョンでは、.a[^.]*間違ってインクルードなどのグロブを取得してしまう.ので、..そうでなければ、最後から2番目のステップを試してみてください。mv FFDC-old/.* FFDC

ext3/ext4のようなファイルシステムは、ディレクトリを基本的にファイル名+inode番号のスペースを持つ移動できないノードのリンクリストとして扱います。ファイルがリンク解除されると、名前のスペースは解放されます（そして、もしあれば、空きの隣接エントリと結合するはずです）。そのため、ファイルが少ない巨大なディレクトリはできる作成することはできますが、簡単ではありません。おそらく、同じファイルへのハード リンクを何百万も作成しているのでしょうか。慎重に作成された名前を持つリンクを何百万も作成または削除しているのでしょうか。何が原因なのかを調査する価値があります。いたずらなのか、何らかのファイルシステムの不具合なのか、...?

関連情報