Faire un rm -rf sur une arborescence de répertoires massive prend des heures

20

Nous utilisons rsnapshot pour les sauvegardes. Il conserve de nombreux instantanés du fichier sauvegardé, mais il supprime les anciens. C'est bon. Cependant, cela prend environ 7 heures pour faire une rm -rfsur une arborescence de répertoires massive. Le système de fichiers est XFS. Je ne sais pas combien de fichiers il y a, mais cela se chiffre probablement en millions.

Y a-t-il de toute façon une accélération? Y a-t-il une commande qui fait la même chose rm -rfet ne prend pas des heures et des heures?

— Rory
source

1

J'ai utilisé find . -delete -name directoryet c'est beaucoup plus rapide que rm -rf.

— Paolo

38

Non.

rm -rfeffectue une traversée récursive en profondeur de votre système de fichiers, en appelant unlink()chaque fichier. Les deux opérations qui ralentissent le processus sont opendir()/ readdir()et unlink(). opendir()et readdir()dépendent du nombre de fichiers dans le répertoire. unlink()dépend de la taille du fichier en cours de suppression. La seule façon d'accélérer le processus consiste à réduire la taille et le nombre de fichiers (ce que je soupçonne peu probable) ou à changer le système de fichiers en un système avec de meilleures caractéristiques pour ces opérations. Je crois que XFS est bon pour unlink () sur de gros fichiers, mais pas si bien pour les grandes structures de répertoires. Vous pourriez trouver que ext3 + dirindex ou reiserfs est plus rapide. Je ne sais pas dans quelle mesure JFS se porte bien, mais je suis sûr qu'il existe de nombreuses références de performances différentes du système de fichiers.

Edit: Il semble que XFS soit terrible pour supprimer des arbres , alors changez définitivement votre système de fichiers.

— David Pashley
source

1

Il y a quelques années, j'ai remarqué des performances terribles en utilisant reiserfs dans un cas d'utilisation similaire.

— knweiss

1

Merveilleux poste!

— wzzrd le

2

Il a presque dit "non" :)

— David Pashley

2

Je suis d'accord avec tout ici, sauf votre déclaration selon laquelle la vitesse de dissociation dépend de la taille du fichier. unlink supprime simplement le lien vers le fichier et ne fait rien au contenu réel. Il ne devrait pas y avoir de différence perceptible entre les fichiers de taille différente (vous pouvez le tester vous-même).

— Kamil Kisiel

@KamilKisiel Vous avez raison de dire que unlinkcela ne fait rien au contenu réel mais pour effectuer un unlinkappel système, le code du système de fichiers a néanmoins plus de travail à faire si le lien supprimé est le dernier du fichier et s'il n'est pas actuellement ouvert. Cela dépend bien sûr du système de fichiers, mais il peut alors y avoir une différence très perceptible lorsque le fichier supprimé est énorme.

— jlliagre

22

Sinon, déplacez le répertoire de côté, recréez-le avec le même nom, les mêmes autorisations et la même propriété et redémarrez toutes les applications / services qui se soucient de ce répertoire.

Vous pouvez ensuite "nice rm" le répertoire d'origine en arrière-plan sans avoir à vous soucier d'une panne prolongée.

— Greg Work
source

Cela pourrait fonctionner, car un mv est très très rapide.

— Rory

Ouaip - ça marche bien. J'ai utilisé cette technique à plusieurs reprises pour «réparer» les boîtes aux lettres basées sur maildir où un client de messagerie a perdu le cerveau et laissé un gâchis sur le disque. Le plus grand répertoire (unique) que j'ai corrigé de cette manière contenait environ 1,5 ou 2 millions de fichiers IIRC. Le temps d'indisponibilité total pour l'utilisateur final était d'environ 3 minutes, dont la plupart attendaient la mort du client de messagerie et des processus d'imap.

— Greg Work

7

Assurez-vous que les bonnes options de montage sont définies pour XFS.

En utilisant -ologbufs = 8, logbsize = 256k avec XFS va probablement tripler vos performances de suppression.

— James
source

2

+1 pour cette astuce ... Il faut également activer les compteurs paresseux pour une autre amélioration des performances.

— hurikhan77

1

Des explications sur ces paramètres seraient utiles aux futurs lecteurs.

— Aron Rotteveel

5

Si vous effectuez le rm efficacement au niveau du fichier, cela prendra beaucoup de temps. C'est pourquoi les instantanés basés sur des blocs sont si bons :).

Vous pouvez essayer de diviser le rm en zones séparées et d'essayer de le faire en parallèle, mais je ne m'attendrais pas à ce qu'il apporte une amélioration. XFS est connu pour avoir des problèmes de suppression de fichiers et si c'est une grande partie de ce que vous faites, alors peut-être un système de fichiers différent serait une idée.

— James
source

Les instantanés basés sur des blocs ne sont pas particulièrement bons dans ce cas. Un certain nombre de systèmes de fichiers --- WAFL et ZFS viennent immédiatement à l'esprit --- fournissent également de bonnes performances pour la suppression d'instantanés. Ils traitent les instantanés comme des objets de système de fichiers de première classe. Ainsi, plutôt que d'itérer (lentement) sur des millions de fichiers pour déterminer les blocs à libérer, ils n'ont qu'à consulter la liste des blocs associée à l'instantané.

— Keith Smith

Hmm. Je me suis probablement senti trop contraire ci-dessus. L'affiche originale doit utiliser Linux, et il n'y a vraiment pas de système de fichiers Linux éprouvé qui fasse des instantanés --- bien que btrfs et nilfs semblent intéressants pour l'avenir. Donc, sur le plan pratique, je suis d'accord - il vaut mieux utiliser des instantanés basés sur des blocs.

— Keith Smith

+1 pour que la pointe divise et parallélise la charge de travail: xfs joue sa force sur les charges de travail parallèles.

— hurikhan77

5

Il est bon d'utiliser ionice pour des opérations gourmandes en E / S comme celle-ci, quel que soit le système de fichiers utilisé.
Je suggère cette commande:

ionice -n7 nice rm -fr dir_name

Il jouera bien pour les opérations en arrière-plan sur le serveur avec une charge IO élevée.

— ash108
source

2

Je sais que c'est vieux, mais je pensais que je jetterais une suggestion. Vous supprimez ces fichiers séquentiellement, l'exécution d'opérations rm parallèles peut accélérer les choses.

http://savannah.nongnu.org/projects/parallel/ parallel peut généralement être utilisé à la place de xargs

donc si vous supprimez tous les fichiers dans deltedir

find -t f deletedir | parallel -j 10 rm

Cela vous laisserait des structures de répertoires vides à supprimer.

Remarque: Vous rencontrerez probablement toujours les limitations du système de fichiers comme indiqué ci-dessus.

— Nick Anderson
source

Quel est l'avantage d'utiliser parallèle sur xargs?

— Rory

1

Une autre option serait-elle de séparer les données de manière à ce que vous puissiez supprimer et reconstruire le système de fichiers réel au lieu de faire le rm?

— Meuglement
source

3

Je pense que rsnapshot utilise des liens durs dans le cadre de la fonction de maintenance-plusieurs-instantanés-efficace. Donc, si l'auteur de la question utilise cette fonctionnalité en utilisant des systèmes de fichiers séparés, cela ne fonctionnera pas (car vous ne pouvez pas établir de lien physique sur une limite de système de fichiers)

— David Spillett

0

Que diriez-vous de diminuer la gentillesse de la commande? Comme:

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

— RainyRat
source

5

Le goulot d'étranglement n'est pas le planificateur, c'est le système de fichiers, je dirais.

— Manuel Faux

Dans le cas peu probable où le planificateur serait le goulot d'étranglement, vous ne feriez que marteler le sous-système d'E / S plus dur, ce qui rendrait le serveur encore moins utilisable pendant la rm.

— David Mackintosh