Pourquoi mes systèmes de fichiers XFS consomment-ils soudainement plus d’espace et des fichiers fragmentés?

Je fais fonctionner des systèmes de fichiers XFS en tant que partitions de données / de croissance depuis près de 10 ans sur différents serveurs Linux.

J'ai remarqué un phénomène étrange avec les récents serveurs CentOS / RHEL exécutant la version 6.2+.

L'utilisation du système de fichiers stable est devenue très variable après le passage à la version plus récente du système d'exploitation, à partir de EL6.0 et EL6.1. Les systèmes initialement installés avec EL6.2 + présentent le même comportement; montrant des fluctuations aléatoires de l'utilisation du disque sur les partitions XFS (voir la ligne bleue dans le graphique ci-dessous).

Avant et après. La mise à niveau de la version 6.1 à la version 6.2 a eu lieu samedi.

Le graphique d'utilisation du disque du trimestre précédent du même système, montrant les fluctuations de la semaine écoulée.

J'ai commencé à vérifier les systèmes de fichiers pour les fichiers volumineux et les processus emballés (fichiers journaux, peut-être?) J'ai découvert que mes fichiers les plus volumineux contenaient des valeurs différentes de duet ls. Courir duavec et sans le --apparent-sizecommutateur illustre la différence.

# du -skh SOD0005.TXT
29G     SOD0005.TXT

# du -skh --apparent-size SOD0005.TXT
21G     SOD0005.TXT

Une vérification rapide à l'aide de l' utilitaire ncdu sur l'ensemble du système de fichiers a permis d'obtenir:

Total disk usage: 436.8GiB  Apparent size: 365.2GiB  Items: 863258

Le système de fichiers est plein de fichiers fragmentés, avec près de 70 Go d'espace perdu par rapport à la version précédente du système d'exploitation / noyau!

J'ai parcouru le Red Hat Bugzilla et modifié les journaux pour voir s'il existait des rapports du même comportement ou de nouvelles annonces concernant XFS.

Nada.

Je suis passé de la version 2.6.32-131.17.1.el6 du noyau à 2.6.32-220.23.1.el6 pendant la mise à niveau; aucun changement dans le numéro de version mineur.

J'ai vérifié la fragmentation de fichier avec l' filefragoutil. Certains des plus gros fichiers de la partition XFS avaient des milliers d'extensions. L'exécution d'une défragmentation en ligne avec xfs_fsr -vune période d'activité lente a permis de réduire temporairement l'utilisation du disque (voir mercredi dans le premier graphique ci-dessus). Cependant, l'utilisation a augmenté dès que l'activité du système a repris.

Que se passe-t-il ici?

J'ai remonté ce problème à une discussion sur un engagement dans l' arborescence des sources XFS à partir de décembre 2010. Le correctif a été introduit dans le noyau 2.6.38 (et, bien entendu, reporté ultérieurement dans certains noyaux de distribution Linux populaires).

Les fluctuations observées de l'utilisation du disque résultent d'une nouvelle fonctionnalité. Pré-affectation EOF spéculative dynamique XFS .

Il s’agit là d’une initiative visant à réduire la fragmentation des fichiers lors des écritures en streaming en allouant de manière spéculative de l’espace à mesure que la taille des fichiers augmente. La quantité d'espace préalloué par fichier est dynamique et dépend principalement de l'espace disponible sur le système de fichiers (pour éviter de manquer totalement d'espace).

Il suit ce calendrier:

freespace       max prealloc size
  >5%             full extent (8GB)
  4-5%             2GB (8GB >> 2)
  3-4%             1GB (8GB >> 3)
  2-3%           512MB (8GB >> 4)
  1-2%           256MB (8GB >> 5)
  <1%            128MB (8GB >> 6)

C'est un ajout intéressant au système de fichiers, car il peut aider certains des fichiers très fragmentés que je traite.

L'espace supplémentaire peut être récupéré temporairement en libérant le pagecache, les dentries et les inodes avec:

sync; echo 3 > /proc/sys/vm/drop_caches

La fonctionnalité peut être entièrement désactivée en définissant une allocsizevaleur lors du montage du système de fichiers. La valeur par défaut pour XFS est allocsize=64k.

L’impact de ce changement sera probablement ressenti par les systèmes de surveillance / de seuillage (c’est ce que j’ai compris), mais a également affecté les systèmes de base de données et pourrait entraîner des résultats imprévisibles ou non souhaités pour les machines virtuelles et les matrices de stockage à provision dynamique (ils utiliseront plus d'espace que prévu

Dans l’ensemble, cela m’a pris au dépourvu parce qu’il n’y avait aucune annonce claire du changement de système de fichiers au niveau de la distribution ou même lors du contrôle de la liste de diffusion XFS .

Edit : Les
performances sur les volumes XFS avec cette fonctionnalité sont considérablement améliorées. Je constate une fragmentation constante <1% sur des volumes qui affichaient auparavant une fragmentation allant jusqu'à 50%. Ecrire performance est globalement en hausse!

Statistiques du même ensemble de données, comparant l'ancien système XFS à la version de EL6.3.

Vieux:

# xfs_db -r -c frag /dev/cciss/c0d0p9
actual 1874760, ideal 1256876, fragmentation factor 32.96%

Nouveau:

# xfs_db -r -c frag /dev/sdb1
actual 1201423, ideal 1190967, fragmentation factor 0.87%