Supprimer 10M + fichiers de ZFS, efficacement

30

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?

nagylzs
la source
1
Je ne suis pas un expert zfs, donc je ne peux pas parler de votre réglage des performances ou de ce que vous pourriez faire pour l'améliorer (cela prendrait également beaucoup d'informations et serait probablement mieux fait directement par un expert). Cependant, je peux dire que la réargenture se produit au niveau du bloc, tandis que vos suppressions se produisent au niveau du système de fichiers. Le système de fichiers aura surtout des frais généraux lors de la suppression d'un bagillion de tampons d'inode comme celui-ci.
Spooler
Veuillez poster vos df -het zpool listet zfs list.
ewwhite
5
Écrit un autre programme: rm -rf /tmp2ne fera pas le travail?
Thorbjørn Ravn Andersen
2
Ne pourriez-vous pas simplement redémarrer? /tmpdevrait être un tmpfssystème de fichiers et est stocké en mémoire.
Blender

Réponses:

31

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.

ewwhite
la source
1
@nagylzs Dans ce cas, je suggérerais d'en faire un système de fichiers ZFS distinct. Ensuite, vous pouvez déplacer le / tmp actuel, déplacer un nouveau / tmp en place et supprimer les fichiers à votre guise. Résultat: temps d'arrêt minimal plus une légère dégradation des performances (atténuable avec ionice, en supposant que FreeBSD en dispose) pendant la suppression.
un CVn du
9
J'avais tort. C'était un système de fichiers séparé. Voici ce qui a fonctionné: redémarrez en mode mono-utilisateur, puis faites "zfs delete zroot / tmp; zfs create zroot / tmp; chmod 41777 / tmp"
nagylzs
6
C'était un temps d'arrêt total de 5 minutes. Fantastique! :-)
nagylzs
1
Eh bien, cela reflète également la préoccupation que j'avais, que la suppression de pics ne libère jamais d'espace à cause des instantanés. Mais tmp sera configuré pour ne pas faire d'instantanés périodiques automatiques, non ?
JDługosz
1
En fait, c'était: zfs create -o compression = on -o exec = on -o setuid = off zroot / tmp; chmod 1777 / zroot / tmp; zfs set mountpoint = / tmp zroot / tmp; Je ne sais pas comment désactiver les instantanés automatiques. Il y a "zfs set com.sun: auto-snapshot = false" mais cela ne fonctionne que sur Solaris, je pense.
nagylzs
27

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é.

Phill W.
la source
5
ZFS n'est pas un immeuble de bureaux :)
developerbmw
9
@developerbmw, il n'y a pas non plus de fichier ou de dossier, mais nous avons besoin de concepts métaphoriques pour comprendre ce qui se passe.
JamesRyan
2
@JamesRyan yep c'est en fait une belle analogie ... J'étais juste stupide
developerbmw
5

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.
Ian Howson
la source
Je ne connais pas ZFS, mais certains systèmes de fichiers vous permettent de dissocier un répertoire avec du contenu, mais de supprimer ce contenu plus tard au cours d'une phase de collecte / défragmentation / nettoyage. Est-ce que ZFS a des utilitaires pour faire une telle suppression paresseuse peut-être? Cela n'accélérera pas réellement la suppression du PO, mais le rendrait probablement moins problématique s'il se produit implicitement pendant l'entretien ménager.
Vality
2

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?

AnoE
la source
2

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.

bwDraco
la source
2

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.

Ole Tange
la source
0

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)

peter
la source
Tout d'abord copier tout sauf / tmp? Donc, y compris / dev et / proc? Deuxièmement, sonne un peu maladroit, surtout sur un serveur de production.
Hennes
Je suppose qu'il est assez intelligent pour exclure les non-fichiers, les volumes montés et le dossier de mémoire virtuelle, dont la plupart ne peuvent pas être devinés ici. Ou faites-le à partir d'un démarrage de maintenance où aucune de ces choses n'a d'importance.
Peter
Je pense que vous pouvez également zfs send/recv(copie au niveau du bloc) tous les autres systèmes de fichiers à l'exception du système de fichiers racine (où / tmp se trouve dans ce cas) et copier manuellement les données restantes sur le système de fichiers racine (à l'exclusion de / tmp bien sûr).
user121391
2
Cela perdra les instantanés et contournera certaines des fonctionnalités de fiabilité. Manque le point d'utiliser zfs.
JDługosz
2
@ JDługosz points valides, mais uniquement pertinents si l'utilisateur s'en soucie. Un peu comme "mes sauvegardes sont corrompues, comment réparer?" -> "Avez-vous besoin de fichiers de sauvegarde?" -> "Non" -> "Reformater".
peter
-1

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.

Paul Smith
la source
1
Je pense que vous avez mal compris la question. J'avais besoin de supprimer la plupart des fichiers. Autrement dit, plus de 30 millions de fichiers.
nagylzs
@nagylzs / tmp est effacé au redémarrage. Si vous souhaitez supprimer le plus , vous ne devez en conserver que quelques - uns , c'est-à-dire moins de la moitié, alors copiez ceux que vous souhaitez conserver, puis redémarrez pour vous débarrasser du reste. La raison pour laquelle vos suppressions sont si lentes est que le fait d'avoir un grand nombre de fichiers dans un répertoire entraîne une grande liste non triée qui doit être traitée pour trouver le fichier à opérer, ce qui prend du temps. Le seul problème ici est PEBCAK.
Paul Smith
Les répertoires ZFS ne sont pas triés ? Je pensais que zfs traitait bien les gros répertoires.
JDługosz
Eh bien, / tmp n'est pas effacé, seuls les fichiers liés à X. Au moins sur FreeBSD. De toute façon, il ne peut pas être effacé au démarrage, car il faudrait des jours pour que le script rc se supprime normalement.
nagylzs
@JDlugosz - ZFS est bien meilleur que la plupart, mais les listes d'inodes (qui sont tous les répertoires) ne sont pas triées.
Paul Smith