Perché rm è lento su un'unità di archiviazione esterna (collegata tramite USB, digitare fuseblk) con 50 GB di file?

21

Ho provato a usare rsnapshot per fare i backup, ma lo trovo inutilizzabile. Mentre è in grado di diff una directory (50 GB) e duplicarla (linkando ogni file) in pochi minuti, e posso cp l'intera directory in circa mezz'ora, ci vuole ben più di un'ora per eliminarla. Anche usando direttamente rm -rfv, trovo che può richiedere fino a mezzo secondo per eseguire il rm di un singolo file, mentre i comandi cpe si linkcompletano all'istante.

Perché rm è così lento? Esiste un modo più rapido per rimuovere ricorsivamente i collegamenti fisici? Non ha senso per me che copiare un file dovrebbe richiedere meno tempo che rimuoverlo.

Il filesystem su cui sto lavorando è un'unità di archiviazione esterna, collegata via USB e digita fuseblk (che penso significhi che è NTFS). Il mio computer esegue Ubuntu Linux.

Uscita dall'alto:

Cpu(s):  3.0%us,  1.5%sy,  0.0%ni, 54.8%id, 40.6%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:   8063700k total,  3602416k used,  4461284k free,   557604k buffers

performance rm external-hdd

— Benubird
fonte

1

Essere montato come fuseblknon significa che l'unità è NTFS, significa solo che è montato come dispositivo a blocchi FUSE. Potrebbe essere quasi tutto.

— Chris Down,

1

@ChrisDown Vero, ma so che è NTFS o ext3, e sono abbastanza sicuro che se fosse ext3 sarebbe montato come tale da mount senza argomenti.

— Benubird,

1

Dipende da quanti file ci sono nella directory (non hai detto quanti), e in particolare NTFS rallenta con solo> 3K file nella directory. Praticamente ogni altro filesystem è molto più performante. Vedi tutti gli altri post su SO / SE sull'effetto del numero di file sulle prestazioni del filesystem.

— smci,

28

In definitiva, qualunque cosa tu faccia, rmdeve essere eseguito unlinksu ogni singolo file che desideri rimuovere (anche se chiami rm -rsulla directory principale). Se ci sono molti file da rimuovere, ciò può richiedere molto tempo.

Esistono due processi particolarmente dispendiosi in termini di tempo quando si esegue rm -r:

readdir, seguito da,
un numero di chiamate a unlink.

Trovare tutti i file e quindi esaminare ogni singolo file per rimuoverlo, può richiedere molto, molto tempo.

Se lo trovi "inutilizzabile" perché rende inutilizzabile la directory per qualche tempo, considera di spostare la directory principale prima di rimuoverla. Questo libererà quel nome per il programma da riutilizzare, senza che il tempo sia troppo scomodo.

Supponendo che il file system in realtà è NTFS (non è chiaro dalla tua domanda), NTFS è generalmente abbastanza lento a cancellazione di ampie fasce di file. Potresti prendere in considerazione l'utilizzo di un filesystem più adatto ai tuoi scopi (i filesystem ext più recenti hanno prestazioni di cancellazione piuttosto buone, se non hai altre esigenze particolari). Anche FUSE stesso non è particolarmente veloce, in generale. Potresti considerare di vedere se riesci a farlo in un modo che non utilizza FUSE.

— Chris Down
fonte

2

+1 Dipende molto dall'esatto file system - molti tendono a funzionare davvero bene per alcune operazioni pur essendo lenti con altri (spesso questo è per la creazione di file vs. rimozione vs. accesso ai dati).

— peterph

15

Perché rm è così lento? Non ne ho idea. Ma conosco un modo più veloce:

mkdir blank
rsync -a --delete blank/ test/

Aggiornamento: questa risposta su Serverfault ha alcune spiegazioni. Sembra che rsync stia eliminando i file in un ordine particolare che fa sì che l'albero dei filesystem rimanga bilanciato e non abbia mai bisogno di essere ribilanciato. rm eliminerà semplicemente i file e causerà molti riequilibri man mano che vengono rimossi. Ci sono alcune informazioni sul riequilibrio qui .

— rjmunro
fonte

1

Hai confrontato questo e confrontato con rm -rf? rsyncdeve ancora contenere unlink()tutti i file test/e questo è probabilmente ciò che richiede tempo.

— MattBianco,

Non l'ho benchmarkato formalmente, ma l'ho provato dopo aver letto i benchmark di qualcun altro e la differenza era sostanziale. Non riesco più a trovare quel post, ma questa risposta su serverfault ha una spiegazione e una fonte per un programma di eliminazione ancora più veloce.

— rjmunro,

Ma il metodo più veloce deve essere unlink(2)nella directory (e ricordarsi di farlo in un fscksecondo momento) ...

— MattBianco

Un fatto è un fatto. L'ho appena cronometrato ed è quasi il doppio più veloce. Dopo aver letto il codice GNU coreutils rm, non mi fa nemmeno meravigliare ...

— Dominik George

1

Bene, una volta ho avuto un problema simile con il tuo. Ho scoperto che il tuo "wa" è alto, che potresti usare

iostat -x 1

per verificare se l'utilizzo del disco è elevato, in tal caso significa che il disco è piuttosto occupato. Verifica se alcuni altri processi scrivono continuamente su disco.

Per semplicità, utilizzare

vmstat 1

per verificare se b è alto o r < b . Ciò indica qualcosa di sbagliato. Nella tua situazione, penso che il disco io sia la ragione originale.

— Fibonacci
fonte