Fare un rm -rf su un enorme albero di directory richiede ore

20

Stiamo usando rsnapshot per i backup. Mantiene molte istantanee del file di backup, ma elimina quelle vecchie. Questo è buono. Tuttavia, ci vogliono circa 7 ore per eseguire una rm -rfsu un enorme albero di directory. Il filesystem è XFS. Non sono sicuro di quanti file ci siano, ma probabilmente sono milioni.

Esiste un modo per accelerarlo? Esiste un comando che fa lo stesso rm -rfe non richiede ore e ore?

— Rory
fonte

1

Ho usato find . -delete -name directoryed è molto più veloce di rm -rf.

— Paolo,

38

No.

rm -rfesegue un attraversamento in profondità ricorsivo del primo filesystem, invocando unlink()ogni file. Le due operazioni che fanno rallentare il processo sono opendir()/ readdir()e unlink(). opendir()e readdir()dipendono dal numero di file nella directory. unlink()dipende dalla dimensione del file da eliminare. L'unico modo per farlo più veloce è ridurre le dimensioni e il numero di file (che sospetto non sia probabile) o cambiare il filesystem in uno con caratteristiche migliori per quelle operazioni. Credo che XFS sia buono per unlink () su file di grandi dimensioni, ma non è così buono per strutture di directory di grandi dimensioni. Potresti scoprire che ext3 + dirindex o reiserfs è più veloce. Non sono sicuro di quanto siano valide le tariffe JFS, ma sono sicuro che ci sono molti parametri di riferimento per le diverse prestazioni del file system.

Modifica: sembra che XFS sia terribile nell'eliminare alberi , quindi cambia decisamente il tuo filesystem.

— David Pashley
fonte

1

Alcuni anni fa ho notato prestazioni terribili usando reiserfs in un caso d'uso simile.

— knweiss,

1

Post meraviglioso!

— wzzrd,

2

Diceva quasi "no" :)

— David Pashley il

2

Sono d'accordo con tutto qui a parte la tua affermazione che la velocità di scollegamento dipende dalla dimensione del file. unlink rimuove semplicemente il collegamento al file e non fa nulla per il contenuto effettivo. Non ci dovrebbero essere differenze distinguibili tra file di dimensioni diverse (puoi provare tu stesso).

— Kamil Kisiel,

@KamilKisiel Hai ragione nel dire unlinkche non fa nulla al contenuto reale ma per eseguire una unlinkchiamata di sistema, il codice del file system ha comunque più lavoro da fare se il collegamento rimosso è l'ultimo al file e se non è attualmente aperto. Questo ovviamente dipende dal file system ma può esserci una differenza molto evidente quando il file rimosso è enorme.

— jlliagre,

22

In alternativa, sposta la directory da parte, ricreala con lo stesso nome, autorizzazioni e proprietà e riavvia tutte le app / i servizi che si occupano di quella directory.

È quindi possibile "rm bello" la directory originale in background senza doversi preoccupare di un'interruzione prolungata.

— Greg Work
fonte

Potrebbe funzionare, dal momento che un mv è molto molto veloce.

— Rory,

Sì, funziona bene. Ho usato questa tecnica molte volte per "riparare" caselle di posta basate su maildir in cui un client di posta elettronica ha perso il cervello e ha lasciato un casino sul disco. La più grande (singola) directory che ho sistemato in questo modo aveva circa 1,5 o 2 milioni di file IIRC. Il tempo di inattività totale per l'utente finale è stato di ~ 3 minuti, la maggior parte dei quali era in attesa che il client di posta e i processi imap morissero.

— Greg Work,

7

Assicurati di avere le giuste opzioni di montaggio impostate per XFS.

Usando -ologbufs = 8, logbsize = 256k con XFS probabilmente triplicherà le tue prestazioni di cancellazione.

— Giacomo
fonte

2

+1 per questo suggerimento ... Uno dovrebbe anche abilitare i contatori pigri per un altro aumento delle prestazioni.

— hurikhan77,

1

Alcune spiegazioni su queste impostazioni sarebbero utili per i futuri lettori.

— Aron Rotteveel,

5

Se stai eseguendo l'rm efficacemente a livello di file, ci vorrà molto tempo. Questo è il motivo per cui gli snapshot basati su blocchi sono così buoni :).

Potresti provare a dividere l'rm in aree separate e provare a farlo in parallelo, ma non mi aspetto che faccia miglioramenti. È noto che XFS ha problemi nell'eliminazione dei file e se questa è una grande parte di ciò che fai, forse un diverso file system sarebbe un'idea.

— Giacomo
fonte

Gli snapshot basati su blocchi non sono unicamente validi in questo caso. Un certo numero di file system --- WAFL e ZFS vengono subito in mente --- forniscono anche buone prestazioni per l'eliminazione di istantanee. Trattano le istantanee come oggetti di file system di prima classe. Quindi, piuttosto che iterare (lentamente) su milioni di file per determinare quali blocchi liberare, devono solo cercare un elenco di blocchi associato all'istantanea.

— Keith Smith,

Hmm. Probabilmente sono venuto fuori come troppo contrario sopra. Il poster originale deve usare Linux, e in realtà non esiste un file system Linux ben collaudato che esegua snapshot, sebbene btrfs e nilfs siano interessanti per il futuro. Quindi, in pratica, sono d'accordo --- meglio usare istantanee basate su blocchi.

— Keith Smith,

+1 per la punta per dividere e parallelizzare il carico di lavoro: xfs gioca la sua forza su carichi di lavoro paralleli.

— hurikhan77,

5

È utile usare ionice per operazioni ad alta intensità di IO come quella indipendentemente dal filesystem utilizzato.
Suggerisco questo comando:

ionice -n7 nice rm -fr nome_dir

Funzionerà bene per operazioni in background su server con carico di I / O pesante.

— ash108
fonte

2

So che questo è vecchio, ma ho pensato di dare un suggerimento. Stai eliminando quei file in sequenza, l'esecuzione di operazioni rm parallele potrebbe velocizzare le cose.

http://savannah.nongnu.org/projects/parallel/ parallel può essere comunemente usato al posto di xargs

quindi se stai eliminando tutti i file in deltedir

find -t f deletedir | parallel -j 10 rm

Ciò ti lascerebbe con solo strutture di directory vuote da eliminare.

Nota: probabilmente continuerai a colpire le limitazioni del filesystem come indicato sopra.

— Nick Anderson
fonte

Qual è il vantaggio dell'utilizzo di parallel over xargs?

— Rory,

1

Un'opzione alternativa qui sarebbe quella di separare i dati in modo tale da poter spazzare e ricostruire il vero filesystem invece di fare l'rm?

— Muggire
fonte

3

Penso che rsnapshot utilizzi hard-link come parte della funzione di mantenimento di più istantanee in modo efficiente. Quindi, se l'interrogante sta usando quella funzione usando filesystem separati non funzionerà (dato che non è possibile effettuare un hard link su un limite del filesystem)

— David Spillett,

0

Che ne dici di diminuire la gentilezza del comando? Piace:

nice -20 rm -rf /path/to/dir/

— RainyRat
fonte

5

Il collo di bottiglia non è lo scheduler, è il file system, direi.

— Manuel Faux,

Nel caso improbabile che lo scheduler sia il collo di bottiglia, si finirà per martellare il sottosistema I / O più difficile, rendendo il server ancora meno utilizzabile durante l'rm.

— David Mackintosh,