回答:
いや
rm -rfファイルシステムの再帰的な深さ優先走査をunlink()行い、すべてのファイルを呼び出します。プロセスの速度を低下させる2つの操作はopendir()/ readdir()とunlink()です。opendir()またreaddir()、ディレクトリ内のファイルの数に依存します。unlink()削除されるファイルのサイズに依存します。これを速くするための唯一の方法は、ファイルのサイズと数を減らすか（おそらくそうではないと思う）、ファイルシステムをそれらの操作の特性がより良いものに変更することです。XFSは大きなファイルのunlink（）には適していると思いますが、大きなディレクトリ構造にはあまり適していません。ext3 + dirindexまたはreiserfsの方が速い場合があります。JFSがどれだけうまくいくかはわかりませんが、さまざまなファイルシステムパフォーマンスのベンチマークがたくさんあると確信しています。
編集：XFSはtreesの削除がひどいようですので、間違いなくファイルシステムを変更してください。
unlink実際のコンテンツには何もしませんが、unlinkシステムコールを実行するには、削除されたリンクがファイルの最後のリンクであり、現在開いていない場合、ファイルシステムコードはそれ以上の作業が必要です。これはもちろんファイルシステムに依存しますが、削除されたファイルが巨大な場合は非常に識別可能な違いがあります。
別の方法として、ディレクトリを別の場所に移動し、同じ名前、権限、所有権で再作成し、そのディレクトリを気にするアプリ/サービスを再起動します。
その後、長時間の停止を心配することなく、バックグラウンドで元のディレクトリを「素敵な状態」にすることができます。
XFSに適切なマウントオプションが設定されていることを確認してください。
XFSで-ologbufs = 8、logbsize = 256kを使用すると、おそらく削除パフォーマンスが3倍になります。
ファイルレベルで効果的にrmを実行している場合は、時間がかかります。これが、ブロックベースのスナップショットが非常に優れている理由です:)。
rmを別々の領域に分割して並行して実行することもできますが、改善されるとは思わないかもしれません。XFSにはファイルの削除に問題があることが知られており、それがあなたのすることの大部分を占める場合は、そのための別のファイルシステムが考えられるでしょう。
私はこれが古いことを知っていますが、私は提案でid tossを考えました。これらのファイルを順番に削除しているので、並列rm操作を実行すると速度が上がる場合があります。
http://savannah.nongnu.org/projects/parallel/ parallelは一般的にxargsの代わりに使用できます
したがって、deltedirのすべてのファイルを削除する場合
find -t f deletedir | parallel -j 10 rm
これにより、削除する空のディレクトリ構造だけが残ります。
注：上記のファイルシステムの制限にまだ達する可能性があります。
ここでの代替オプションは、rmを実行する代わりにジャンクして実際のファイルシステムを再構築できるような方法でデータを分離することでしょうか？
コマンドの良さを減らすのはどうですか？のような：
nice -20 rm -rf /path/to/dir/
find . -delete -name directory、それははるかに高速ですrm -rf。