Dosyaları neden ada göre silmek acı verici derecede yavaş ve aynı zamanda son derece hızlı?

Sahte pas: Aşağıda bahsettiğim "hızlı" yöntem, yavaş olandan 60 kat daha hızlı değildir. 30 kat daha hızlı. Saatteki hatayı suçlayacağım (3AM, net düşünme için günün en iyi zamanı değil :) ..

Güncelleme: Test sürelerinin bir özetini ekledim (aşağıda).
Hız faktörü ile ilgili iki sorun var gibi görünüyor:

• Kullanılan komut seçimi (Zaman karşılaştırmaları aşağıda gösterilmiştir)
• Bir dizindeki çok sayıda dosyanın doğası ... Görünüşe göre "büyük kötü". Sayılar arttıkça işler orantısız bir şekilde yavaşlar.

Tüm testler 1 milyon dosya ile yapılmıştır.
(gerçek, kullanıcı ve sys süreleri test komut dosyalarındadır)
Test komut dosyalarını paste.ubuntu.com adresinde bulabilirsiniz.

#
# 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
#                                                       

Kısa süre önce 10 milyon boş test dosyası oluşturdum ve sildim . Dosyaları isme göre isimle (yani rm filename) silerek , 2 farklı yöntem arasında büyük bir zaman farkı olduğunu öğrendim ...

Her iki yöntem de aynı rm filenamekomutu kullanır.

Güncelleme: ortaya çıktığı gibi, komutlar tam olarak aynı değildi ... Bunlardan biri 'rm' için bir seferde 1000 dosya adı gönderiyordu ... Her dosya adının yazıldığını düşündüğüm bir kabuk ayracı genişletme sorunuydu besleyici dosyasına kendi satırında, ancak aslında satır başına 1000'di

Dosya adları bir 'besleyici dosyası' aracılığıyla bir while readdöngüye sağlanır.
Besleyici dosyası çıktısıdır ls -1 -f
Yöntemler tek bir şey hariç tüm yeniden değerlendirmelerde aynıdır:

• Yavaş yöntem doğrudan sıralanmamış besleyici dosyası kullanırls -1 -f
• hızlı yöntem aynı ayıklanmamış dosyanın sıralanmış bir sürümünü kullanır

Sıralama burada ths sorunu olup olmadığından emin değilim, ya da belki de sıralanmış besleyici dosyası sadece dosyaların oluşturulduğu sırayla eşleşir mi (basit bir artan tamsayı algoritması kullandım)

1 milyon dosya için, hızlı rm filename yöntem yavaş yöntemden 60 kat daha hızlıdır ... yine, bunun bir "sıralama" sorunu mu yoksa sahne arkasındaki karma tablo sorunu mu bilmiyorum ... bu basit bir sıralama sorunu değildir, çünkü neden bana kasıtlı olarak yeni eklenen "sıralanmış" bir dosya adı dizisinin sıra dışı bir listesini vereyim ... ls -1 -f

Sadece burada neler olduğunu merak ediyorum, bu yüzden önümüzdeki 10 milyon dosyayı silmek günlerimi (evet günler) almıyor :) .... "günler" diyorum çünkü birçok alternatif denedim ve ilgili zamanlar, söz konusu dosyaya orantısız bir şekilde arttı .. bu yüzden sadece 1 milyon ayrıntılı test yaptım

BTW: Dosyaların "sıralı liste" yoluyla silinmesi aslında rm -rf2 katına göre daha hızlı
ve: rm -r"sıralı liste" yönteminden 30 kat daha yavaştı

... ama sorun burada "sıralanıyor" mu? veya daha çok ext4 tarafından kullanılan bir karma (veya her ne olursa olsun) depolama yöntemiyle mi ilgili?

Beni oldukça şaşırtan şey, her çağrının rm filenamebir öncekiyle ilgisiz olmasıdır. (En azından 'bash' perspektifinden bu şekilde)

Ubuntu / bash / 'ext4' / SATA II sürücüsünü kullanıyorum.

rm -r'nin özyinelemeli olarak yavaş olması beklenir. Dizin yapısında bir derinlik ilk geçişi yapılmalıdır.

Şimdi 10 milyon dosyayı nasıl oluşturdunuz? u bazı sipariş döngüleri bazı komut dosyası kullandınız mı? 1.txt, 2.txt, 3.txt ... evetse, bu dosyalar da hdd'deki bitişik bloklarda aynı sırayla tahsis edilebilir. Böylece aynı sırayla silmek daha hızlı olacaktır.

"ls -f" özyinelemeli dizin sırasına göre listelenen -aU'yu etkinleştirir.

Dosya yapısını optimize etmelisiniz. Yani yerine

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

daha akıllıca bir şey yap (bash varsayılır):

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

Şimdi bu örnek, md5sum [1] kullanımı nedeniyle oldukça yavaştır, herhangi bir dosya adına ihtiyacınız olmadığı sürece, kopyaların endişe duymadığı ve belirli bir ismin tekrarlanabilir karması :)

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

Tabii ki bu tüm hashtables kavramları özensiz ödünç