回答:
あなたは、ディレクトリのinodeをリンク解除を試みることができるが、それは孤立ファイルの全負荷であなたを残してfsck ます についてフリップアウト。
rm それが得るほど良いです。
一部の人は他の人よりも高速であるというエッジケースに言及しています。しかし、同じものの最良のバージョンを比較していることを確認しましょう。
ディレクトリとその中のすべてを削除したい場合、私はあなたに提案しています：
rm -rf path/to/directory
rm削除するファイルとディレクトリを内部的にリストします。そして、それはすべてコンパイルされたCにあります。最速であるのは、これらの2つの理由です。
これは非常にあからさまと同じことではないrm -rf path/to/directory/*であろう展開するシェルレベルとに引数の負荷を渡しますrm。次に、rmそれらを解析し、それぞれから再帰する必要があります。それはずっと遅いです。
比較する「ベンチマーク」find path/to/directory -exec {} \;はナンセンスです。実行されることrmに見つかったファイルごとに一度。とても遅いです。Findはxargsスタイルでコマンド引数をビルドできます-exec rm {} +が、それは展開と同じくらい遅いです。カーネルへの-delete内部呼び出しを使用して呼び出すことができunlinkます（rmそうします）が、最初はファイルに対してのみ機能します。
繰り返しますが、ディスクを液体の熱いマグマに入れない限り、rm王様です。
関連するメモでは、ファイルシステムが異なると、その構造が異なるため、異なる速度で削除されます。定期的にこれを行っている場合は、これらのファイルを、削除を非常に高速に処理する傾向があるXFSでフォーマットされたパーティションに保存することができます。
または、より高速なディスクを使用します。RAMが大量にある場合は、/dev/shm（RAMディスク）を使用することをお勧めします。
unlinkにディレクトリでシステムコールを使用することはできません（EISDIRエラーが発生します）。そのため、最初のオプションは使用できません。
mv異なるファイルシステム/パーティション間でのingは、cp後にaが続くことを意味しますrm。
/tmpが同じファイルシステム上にある場合mv、再起動の方が速くなるのだろうか？とにかく/tmp使用しrmてクリアされるかどうかはわかりません。
時には、find $DIR_TO_DELETE -type f -deleteよりも高速ですrm -rf。
また、試してみたいかもしれませんmkdir /tmp/empty && rsync -r --delete /tmp/empty/ $DIR_TO_DELETE。
最後に、パーティション全体のコンテンツを削除する必要がある場合、おそらく最速はumountでmkfsあり、再mountです。
type -fディレクトリではなくファイルを示すのではないですか？また、追加-printすると、削除中のファイルが表示されます。
空き領域が必要ない場合は、削除を遅らせてバックグラウンドで実行するのが最も簡単な方法です。
次に、I / Oの優先度が低く、静かな時間にバックグラウンドで実行するcrontabを用意します。
3 3 * * * root ionice -c 3 nice find /path/to/.delete_me -maxdepth 1 ! -name \. -exec echo rm -rf "{}" +
ノート：
更新：複数のrmを並行して実行するための巧妙なトリックを見つけました-これは、大きなディスクアレイがある場合に役立ちます。
ionice -c 3 nice find target_directory -depth -maxdepth 3 | xargs -d \n -P 5 -n 5 rm -rf
-深さ優先走査を行う深さ。
-maxdepthにより、ディレクトリトラバーサルの深さを制限し、個々のファイルをリッスンしないようにします。
-d \ nファイル名のスペースを処理します。
-Pおよび-nは並列度を処理します（マンページを確認してください）。
ref：http : //blog.liw.fi/posts/rm-is-too-slow/#comment-3e028c69183a348ee748d904a7474019
更新2（2018）：Ubuntu 18.04に同梱されているZFSを使用して、すべてに使用し、大きなプロジェクト用に新しいデータセットを作成します。事前に計画して事前にこれを行う場合、完了時にファイルシステムを「zfs destroy」するだけです。;-)
zfsonlinux wikiの指示を使用して、UbuntuをZFSにネイティブにインストールしました：https : //github.com/zfsonlinux/zfs/wiki/Ubuntu-18.04-Root-on-ZFS
find target_dir -maxdepth 3 -depth -type d -print0 | xargs -0 -P 5 rm -rf。この-depthオプションはfind、最初に子をリストするように指示します。
問題は、非常に大きなディレクトリとそのコンテンツ全体を、リンク解除を理解し、FSCKにないファイルがあるとは思わない真のインデックス付きファイリングシステムなしで削除する完璧な方法がないことだと思います。信頼が必要です。
たとえば、ゴルフ場でゾーンマインダーを実行しています。1.5 TBのlinux raidを作成して、彼女が1日にキャプチャした膨大な量のデータ（12のカメラフィード）を処理しました。要するに、キャプチャされたすべてのデータのフォルダは、ストレージの約1.4 TBです。たくさんのパージ
ZMを再インストールして1.4 TBの古いライブラリを削除する必要はありません。古いイメージを削除するのに1〜2日かかる可能性があるためです。
真のインデックスFSはディレクトリの削除を許可し、その下のデータが無効であり、データのゼロ化が時間とPCリソースの浪費であることを認識します。削除されたデータをゼロにするオプションにする必要があります。RMは、ext4での現実の世界では時間がかかります。
回答：すべてのファイルの再帰的なリンク解除はわずかに速くなりますが、FSCKを実行する時間を確保する必要があります。
フォルダー内のすべてのファイルを「リンク解除」し、すべてのフォルダーをrmまたはrmdirしてクリーンアップできる再帰的な「FOR」コマンドを実行するスクリプトを作成します。必要に応じて、FSCKを手動で実行し、残りのデータをゼロにします。ちょっと怠け者は申し訳ありませんが書きませんでした:)。
既存のディレクトリを削除する場合は便利ではありませんが、定期的に削除する必要がある大量のファイルが含まれるディレクトリがある場合は、そのディレクトリを独自のファイルシステムに配置することをお勧めします（例：パーティション）。その後、パージする必要がある場合は、アンマウントし、aを実行してmkfs再マウントします。たとえば、OpenBSDは/usr/obj、システムのビルド中に多くのファイルが作成され、次のビルドの前に削除する必要があるため、これを行うことをお勧めします。