Perché la cancellazione dei file per nome è dolorosamente lenta e anche eccezionalmente veloce?

Faux pas: Il metodo "veloce" che cito di seguito, non è 60 volte più veloce di quello lento. È 30 volte più veloce. Incolperò l'errore ogni ora (3AM non è il mio momento migliore della giornata per pensare chiaramente :) ..

Aggiornamento: ho aggiunto un riepilogo dei tempi di prova (sotto).
Sembra che ci siano due problemi coinvolti con il fattore velocità:

• La scelta del comando utilizzato (Confronti temporali mostrati di seguito)
• La natura di un gran numero di file in una directory ... Sembra che "big is bad". Le cose diventano sproporzionatamente più lente quando i numeri aumentano.

Tutti i test sono stati eseguiti con 1 milione di file.
(i tempi reali, utente e sys sono negli script di test)
Gli script di test sono disponibili su 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
#                                                       

Di recente ho creato ed eliminato 10 milioni di file di test vuoti. Eliminando i file in base al nome (ad es. rm filename), Ho scoperto che esiste una differenza di tempo enorme tra 2 metodi diversi ...

Entrambi i metodi usano lo stesso rm filenamecomando esatto .

Aggiornamento: a quanto pare, i comandi non erano esattamente gli stessi ... Uno di questi stava inviando 1000 nomi di file alla volta a "rm" ... Era un problema di espansione della shell dove pensavo che ogni nome di file fosse stato scritto al file dell'alimentatore su una riga a sé stante, ma in realtà era 1000 per riga

I nomi dei file vengono forniti tramite un "file feeder" in un while readciclo.
Il file feeder è l'output di ls -1 -f
I metodi sono identici sotto tutti gli aspetti, ad eccezione di una cosa:

• il metodo lento utilizza direttamente il file feeder non ordinatols -1 -f
• il metodo veloce utilizza una versione ordinata dello stesso file non ordinato

Non sono sicuro che l'ordinamento sia il problema qui, o forse è che il file dell'alimentatore ordinato coincide solo con la sequenza in cui sono stati creati i file (ho usato un semplice algoritmo intero crescente)

Per 1 milione di file, il metodo veloce rm filename è 60 volte più veloce del metodo lento ... di nuovo, non so se si tratta di un problema di "ordinamento" o di un problema di tabella hash dietro le quinte ... non è un semplice problema di ordinamento, perché perché ls -1 -fmi darebbe intenzionalmente un elenco non ordinato di una sequenza di nomi di file "ordinati" appena aggiunta ...

Mi sto solo chiedendo cosa sta succedendo qui, quindi non mi ci vogliono giorni (sì giorni) per eliminare i prossimi 10 milioni di file :) .... Dico "giorni" perché ho provato così tante alternative, e il i tempi coinvolti aumentano in modo sproporzionato rispetto al numero di file in questione .. quindi ho testato solo 1 milione in dettaglio

A proposito: l'eliminazione dei file tramite l'elenco "ordinato" dei nomi è in realtà più rapida di rm -rfun fattore 2
e: rm -r30 volte più lenta del metodo "elenco ordinato"

... ma il problema è "risolto" qui? o è più correlato a un metodo di memorizzazione hashing (o altro) utilizzato da ext4?

La cosa che mi confonde abbastanza è che ogni chiamata a rm filenamenon è correlata alla precedente .. (beh, almeno è così dalla prospettiva 'bash')

Sto usando Ubuntu / bash / 'ext4' / unità SATA II.

rm -r dovrebbe essere lento come ricorsivo. È necessario effettuare una prima traversata approfondita sulla struttura delle directory.

Ora come hai creato 10 milioni di file? hai usato qualche script che scorre in qualche ordine? 1.txt, 2.txt, 3.txt ... se sì, anche quei file possono essere allocati nello stesso ordine in blocchi contigui in hdd.so l'eliminazione nello stesso ordine sarà più veloce.

"ls -f" abiliterà -aU che elenca in ordine di directory che è di nuovo ricorsivo.

È necessario ottimizzare la struttura del file. Quindi invece di

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

fare qualcosa di più intelligente (bash ipotizzato):

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

Ora questo esempio è piuttosto lento a causa dell'uso di md5sum [1], usa qualcosa come il seguente per una risposta molto più veloce, finché non hai bisogno di nomi di file particolari, i duplicati non sono preoccupanti e non c'è bisogno di un hash ripetibile di un certo nome :)

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

Ovviamente si tratta di tutti i concetti mutuatamente trascurati dagli hashtabili