名前でファイルを削除するのが非常に遅く、非常に速いのはなぜですか？

Faux pas：私が以下に述べる「速い」方法は遅い方法より60倍速くはありません。30倍高速です。私は時間の間違いを非難します（午前3時は明確な思考のための私の最高の時間ではありません:)。

更新：テスト時間の要約を追加しました（下記）。
速度係数には2つの問題があるようです。

• 使用するコマンドの選択（以下の時間比較）
• ディレクトリ内の多数のファイルの性質...「大きいことは悪いこと」のようです。数値が増加するにつれて、物事は不均衡に遅くなります。

すべてのテストは100万のファイルで行われました。
（実時間、ユーザー時間、sys時間はテストスクリプトに含まれています）
テストスクリプトはpaste.ubuntu.comにあります。

#
# 1 million files           
# ===============
#
#  |time   |new dir   |Files added in  ASCENDING order  
#  +----   +-------   +------------------------------------------------- 
#   real    01m 33s    Add files only (ASCENDING order) ...just for ref.
#   real    02m 04s    Add files, and make 'rm' source (ASCENDING order) 
#                      Add files, and make 'rm' source (DESCENDING order) 
#   real    00m 01s    Count of filenames
#   real    00m 01s    List of filenames, one per line
#   ----    -------    ------
#   real    01m 34s    'rm -rf dir'
#   real    01m 33s    'rm filename' via rm1000filesPerCall   (1000 files per 'rm' call)
#   real    01m 40s    'rm filename' via  ASCENDING algorithm (1000 files per 'rm' call)
#   real    01m 46s    'rm filename' via DESCENDING algorithm (1000 files per 'rm' call)
#   real    21m 14s    'rm -r dir'
#   real    21m 27s    'find  dir -name "hello*" -print0 | xargs -0 -n 1000 rm'
#   real    21m 56s    'find  dir -name "hello*" -delete'
#   real    23m 09s    'find  dir -name "hello*" -print0 | xargs -0 -P 0 rm'
#   real    39m 44s    'rm filename' (one file per rm call) ASCENDING
#   real    47m 26s    'rm filename' (one file per rm call) UNSORTED
#                                                       

最近、1,000万の空のテストファイルを作成して削除しました。名前ごとにファイルを削除すると（つまりrm filename）、2つの異なる方法の間に大きな時間差があるという難しい方法がわかりました...

どちらの方法でも、まったく同じrm filenameコマンドを使用します。

更新：結局のところ、コマンドはまったく同じではありません...それらの1つは一度に1000個のファイル名を 'rm'に送信していました...それは、各ファイル名が書き込まれていると思ったシェルブレース展開の問題でしたそれ自体の行でフィーダーファイルに追加されましたが、実際には1行あたり1000でした。

filnamesは 'フィーダーファイル'を介してwhile readループに提供されます。
フィーダーファイルは次の出力ですls -1 -f
メソッドは、1つの点を除いて、すべての点で同じです。

• 遅い方法はからの直接ソートされていないフィーダファイルを使用していますls -1 -f
• 高速な方法は、同じソートされていないファイルのソートされたバージョンを使用しています

ここでソートが問題であるかどうか、またはソートされたフィーダーファイルがファイルが作成された順序と偶然一致しているのかどうかはわかりません（私は単純な昇順整数アルゴリズムを使用しました）

100万ファイルの場合、高速 rm filenameメソッドは低速メソッドより60倍高速です...繰り返しますが、これが「ソート」の問題なのか、舞台裏のハッシュテーブルの問題なのかはわかりません...これは単純な並べ替えの問題ではありません。なぜ新しく追加された「並べ替えられた」ファイル名のシーケンスの並べ替えられていないリストが意図的に与えられるのですか... ls -1 -f

私はここで何が起こっているのだろうと思っているので、次の1000万のファイルを削除するのに何日も（はい数日）かかりません:) ....私は「日」と言います。倍の関与のnumberOfファイルへdisproportionatly関与増加..私はのみテストしてみたので、1詳しく万人を

ところで：名前の「ソートされたリスト」を介してファイルを削除しても、実際にはより高速であるrm -rf2倍
と：rm -r30倍遅く、「ソートされたリスト」方式を超えました

...しかし、ここで問題を「分類」していますか？それとも、ext4が使用するストレージのハッシング（またはその他の）メソッドにもっと関連していますか？

私をかなり困惑させることは、それぞれの呼び出しがrm filename前の呼び出しと無関係であることです。（まあ、少なくとも「bash」の観点からはそうです）

Ubuntu / bash / 'ext4' / SATA IIドライブを使用しています。

rm -rは再帰的であるため、低速であると予想されます。深さ優先トラバーサルは、ディレクトリ構造で行う必要があります。

では、1,000万のファイルをどのように作成しましたか？ある順序でループするスクリプトを使用しましたか？1.txt、2.txt、3.txt ...はいの場合、それらのファイルは、hdd.so内の隣接するブロックに同じ順序で割り当てられている可能性があるため、同じ順序で削除すると高速になります。

"ls -f"を指定すると-aUが有効になり、ディレクトリの順序でリストが再帰的に表示されます。

ファイル構造を最適化する必要があります。だから代わりに

for i in $(seq 1 1000); do touch file.$i; done

（bashが想定されている）のようなよりスマートなことを行います：

function bucklocate() 
{ 
    hash=$(echo -n "$1"|md5sum|cut -f1); 
    echo -n "${hash:1:1}/${hash:7:1}/${hash:9:2}/$1"; 
}

hexdig="{0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f}"
eval mkdir -p $hexdig/$hexdig/$hexdig$hexdig


for i in $(seq 1 1000); do touch $(bucklocate file.$i); done

md5sum [1]を使用しているため、この例はかなり遅くなります。特定のファイル名が不要で、重複が問題ではなく、特定の名前の繰り返し可能なハッシュ:)

mkdir -pv {0,1,2,3,4,5,6}/{0,1,2,3,4,5,6,7,8,9,10,12}
for  a in $(seq 1 100); do i=$RANDOM; echo touch "$(($i%7))/$(($i%13))/file.$i"; done

もちろん、これはすべてハッシュテーブルから概念をだらしなく借りている