Supprimer 10M + fichiers de ZFS, efficacement

J'ai écrit un programme buggy qui a accidentellement créé environ 30 millions de fichiers sous / tmp. (Le bogue a été introduit il y a quelques semaines et il créait quelques sous-répertoires par seconde.) Je pouvais renommer / tmp en / tmp2, et maintenant je dois supprimer les fichiers. Le système est FreeBSD 10, le système de fichiers racine est zfs.

Pendant ce temps, l'un des disques du miroir a mal tourné et je l'ai remplacé. Le lecteur dispose de deux disques SSD de 120 Go.

Voici la question: le remplacement du disque dur et la réargenture de l'ensemble de la baie ont pris moins d'une heure. La suppression de fichiers / tmp2 est une autre histoire. J'ai écrit un autre programme pour supprimer les fichiers, et il ne peut supprimer que 30 à 70 sous-répertoires par seconde. La suppression de tous les fichiers prendra entre 2 et 4 jours.

Comment est-il possible que la réargenture de l'ensemble de la baie prenne une heure, mais que la suppression du disque prenne 4 jours? Pourquoi mes performances sont-elles si mauvaises? 70 suppressions / seconde semblent très très mauvaises performances.

Je pourrais supprimer manuellement l'inode de / tmp2, mais cela ne libérera pas de l'espace, non?

Serait-ce un problème avec zfs, ou les disques durs ou quoi?

Les suppressions dans ZFS coûtent cher. Encore plus si vous avez activé la déduplication sur le système de fichiers (car le déréférencement des fichiers dédoublés coûte cher). Les instantanés pourraient également compliquer les choses.

Vous feriez mieux de supprimer le /tmprépertoire au lieu des données qu'il contient.

S'il /tmps'agit d'un système de fichiers ZFS, supprimez-le et créez à nouveau.

Comment est-il possible que la réargenture de l'ensemble de la baie prenne une heure, mais que la suppression du disque prenne 4 jours?

Considérons un immeuble de bureaux.

Le retrait de tous les ordinateurs, meubles et fixations de tous les bureaux à tous les étages prend beaucoup de temps, mais laisse les bureaux immédiatement utilisables par un autre client.

Démolissant le bâtiment avec RDX est beaucoup plus rapide, mais le prochain client est tout à fait susceptible de se plaindre de la façon dont l'endroit est mal isolé.

Il se passe un certain nombre de choses ici.

Tout d'abord, toutes les technologies de disques modernes sont optimisées pour les transferts en masse. Si vous devez déplacer 100 Mo de données, ils le feront beaucoup plus rapidement s'ils sont dans un bloc contigu au lieu d'être dispersés partout. Les SSD aident beaucoup ici, mais même ils préfèrent les données dans des blocs contigus.

Deuxièmement, la réargenture est assez optimale en ce qui concerne les opérations sur disque. Vous lisez un énorme bloc contigu de données à partir d'un disque, effectuez des opérations de processeur rapides sur celui-ci, puis le réécrivez dans un autre gros bloc contigu sur un autre disque. Si l'alimentation est coupée à mi-chemin, ce n'est pas grave - vous ignorerez simplement toutes les données avec de mauvaises sommes de contrôle et continuerez comme d'habitude.

Troisièmement, la suppression d'un fichier est vraiment lente . ZFS est particulièrement mauvais, mais pratiquement tous les systèmes de fichiers sont lents à supprimer. Ils doivent modifier un grand nombre de blocs de données différents sur le disque et les chronométrer correctement (c'est-à-dire attendre) afin que le système de fichiers ne soit pas endommagé en cas de panne de courant.

Comment est-il possible que la réargenture de l'ensemble de la baie prenne une heure, mais que la suppression du disque prenne 4 jours?

La réargenture est quelque chose que les disques sont vraiment rapides, et la suppression est quelque chose que les disques sont lents. Par mégaoctet de disque, vous n'avez qu'à faire un peu de réargenture. Vous pourriez avoir mille fichiers dans cet espace qui doivent être supprimés.

70 suppressions / seconde semblent très très mauvaises performances

Ça dépend. Je ne serais pas surpris par cela. Vous n'avez pas mentionné le type de SSD que vous utilisez. Les SSD Intel et Samsung modernes sont plutôt bons dans ce type d'opération (lecture-modification-écriture) et fonctionnent mieux. Les SSD moins chers / plus anciens (par exemple Corsair) seront lents. Le nombre d'opérations d'E / S par seconde (IOPS) est ici le facteur déterminant.

ZFS est particulièrement lent à supprimer des éléments. Normalement, il effectuera des suppressions en arrière-plan afin que vous ne voyiez pas le retard. Si vous en faites un grand nombre, il ne peut pas le cacher et doit vous retarder.

Annexe: pourquoi les suppressions sont-elles lentes?

• La suppression d'un fichier nécessite plusieurs étapes. Les métadonnées du fichier doivent être marquées comme «supprimées», et finalement elles doivent être récupérées afin que l'espace puisse être réutilisé. ZFS est un «système de fichiers structuré de journaux» qui fonctionne mieux si vous ne créez que des choses, ne les supprimez jamais. La structure du journal signifie que si vous supprimez quelque chose, il y a un espace dans le journal et que d'autres données doivent donc être réorganisées (défragmentées) pour combler l'espace. Ceci est invisible pour l'utilisateur mais généralement lent.
• Les modifications doivent être apportées de manière à ce que, en cas de panne de courant à mi-parcours, le système de fichiers reste cohérent. Souvent, cela signifie attendre que le disque confirme que les données se trouvent réellement sur le support; pour un SSD, cela peut prendre du temps (centaines de millisecondes). L'effet net de ceci est qu'il y a beaucoup plus de comptabilité (c'est-à-dire des opérations d'E / S sur disque).
• Tous les changements sont mineurs. Au lieu de lire, d'écrire et d'effacer des blocs flash entiers (ou des cylindres pour un disque magnétique), vous devez en modifier un peu. Pour ce faire, le matériel doit lire dans un bloc ou un cylindre entier, le modifier en mémoire, puis l'écrire à nouveau sur le support. Cela prend beaucoup de temps.

Comment est-il possible que la réargenture de l'ensemble de la baie prenne une heure, mais que la suppression du disque prenne 4 jours?

Cela est possible car les deux opérations fonctionnent sur différentes couches de la pile du système de fichiers. La réargenture peut s'exécuter à bas niveau et n'a pas réellement besoin d'examiner des fichiers individuels, en copiant de gros morceaux de données à la fois.

Pourquoi mes performances sont-elles si mauvaises? 70 suppressions / seconde semblent très très mauvaises performances.

Il faut beaucoup de comptabilité ...

Je pourrais supprimer manuellement l'inode de / tmp2, mais cela ne libérera pas de l'espace, non?

Je ne sais pas pour ZFS, mais s'il pouvait s'en remettre automatiquement, il ferait probablement, en fin de compte, les mêmes opérations que vous faites déjà, en arrière-plan.

Serait-ce un problème avec zfs, ou les disques durs ou quoi?

Dit zfs scrubquelque chose?

Supprimer de nombreux fichiers n'est jamais vraiment une opération rapide.

Pour supprimer un fichier sur un système de fichiers, vous devez lire l'index de fichier, supprimer (ou marquer comme supprimé) l'entrée de fichier dans l'index, supprimer toutes les autres métadonnées associées au fichier et marquer l'espace alloué pour le fichier comme inutilisé. Cela doit être fait individuellement pour chaque fichier à supprimer, ce qui signifie que la suppression de nombreux fichiers nécessite de nombreuses petites E / S. Faire cela d'une manière qui garantit l'intégrité des données en cas de panne de courant ajoute encore plus de surcharge.

Même sans les particularités introduites par ZFS, la suppression de 30 millions de fichiers signifie généralement plus de cent millions d'opérations d'E / S distinctes. Cela va prendre beaucoup de temps , même avec un disque dur SSD. Comme d'autres l'ont mentionné, la conception de ZFS aggrave encore ce problème.

Ian Howson donne une bonne réponse sur la raison pour laquelle il est lent.

Si vous supprimez des fichiers en parallèle, vous pouvez voir une augmentation de la vitesse en raison de la suppression peut utiliser les mêmes blocs et peut ainsi enregistrer la réécriture du même bloc plusieurs fois.

Alors essayez:

find /tmp -print0 | parallel -j100 -0 -n100 rm

et voyez si cela fonctionne mieux que vos 70 suppressions par seconde.

Très simple si vous inversez votre pensée.

1. Obtenez un deuxième disque (vous semblez l'avoir déjà)

2. Copiez tout du lecteur A vers le lecteur B avec rsync, à l'exception du répertoire / tmp. Rsync sera plus lent qu'une copie de bloc.

3. Redémarrez, en utilisant le lecteur B comme nouveau volume de démarrage

4. Reformater le lecteur A.

Cela défragmentera également votre lecteur et vous donnera un nouveau répertoire (bien, la défragmentation n'est pas si importante avec un SSD mais la linéarisation de vos fichiers ne fait jamais de mal)

Vous avez 30 millions d'entrées dans une liste non triée. Vous scannez la liste pour l'entrée que vous souhaitez supprimer et vous la supprimez. Maintenant, vous n'avez plus que 29 999 999 entrées dans votre liste non triée. S'ils sont tous dans / tmp, pourquoi ne pas simplement redémarrer?

Modifié pour refléter les informations dans les commentaires: Énoncé du problème: la suppression de la plupart, mais pas de la totalité , des 30 M + fichiers créés de manière incorrecte dans / tmp prend beaucoup de temps.
Problème 1) Le meilleur moyen de supprimer un grand nombre de fichiers indésirables de / tmp.
Problème 2) Comprendre pourquoi il est si lent de supprimer des fichiers.

Solution 1) - / tmp est réinitialisé à vide au démarrage par la plupart des distributions * nix. FreeBSD n'en fait cependant pas partie.
Étape 1 - copiez les fichiers intéressants ailleurs.
Étape 2 - En tant que root

 $ grep -i tmp /etc/rc.conf  
 clear_tmp_enable="YES" # Clear /tmp at startup.  

Étape 3 - redémarrez.
Étape 4 - remplacez clear_tmp_enable par "Non".
Les fichiers indésirables ont maintenant disparu, car ZFS sur FreeBSD a la fonctionnalité suivante: "La destruction d'un ensemble de données est beaucoup plus rapide que la suppression de tous les fichiers qui résident sur l'ensemble de données, car elle n'implique pas l'analyse de tous les fichiers et la mise à jour de toutes les métadonnées correspondantes. " donc tout ce qu'il a à faire au démarrage est de réinitialiser les métadonnées de l'ensemble de données / tmp. C'est très rapide.

Solution 2) Pourquoi est-ce si lent? ZFS est un merveilleux système de fichiers qui comprend des fonctionnalités telles que l'accès au répertoire à temps constant. Cela fonctionne bien si vous savez ce que vous faites, mais les preuves suggèrent que l'OP n'est pas un expert ZFS. L'OP n'a pas indiqué comment ils tentaient de supprimer les fichiers, mais je suppose qu'ils ont utilisé une variante de "find regex -exec rm {} \;". Cela fonctionne bien avec de petits nombres mais n'est pas évolutif car il y a trois opérations en série en cours 1) obtenir la liste des fichiers disponibles (retourne 30 millions de fichiers dans l'ordre de hachage), 2) utiliser regex pour choisir le fichier suivant à supprimer, 3 ) dire au système d'exploitation de rechercher et de supprimer ce fichier d'une liste de 30 millions. Même si ZFS renvoie une liste de la mémoire et si 'find' le met en cache, l'expression régulière doit toujours identifier le prochain fichier à traiter à partir de la liste, puis dire au système d'exploitation de mettre à jour ses métadonnées pour refléter ce changement, puis de mettre à jour la liste afin qu'il ne soit pas traité à nouveau.