Le système de fichiers XFS est cassé dans RHEL / CentOS 6.x - Que puis-je faire à ce sujet?

Les versions récentes de RHEL / CentOS (EL6) ont apporté des changements intéressants au système de fichiers XFS dont je dépendais fortement depuis plus d'une décennie. J'ai passé une partie de l'été dernier à traquer une situation de fichier épars XFS résultant d'un backport de noyau mal documenté. D'autres ont eu des problèmes de performances malheureux ou un comportement incohérent depuis le passage à EL6.

XFS était mon système de fichiers par défaut pour les données et les partitions de croissance, car il offrait stabilité, évolutivité et une bonne amélioration des performances par rapport aux systèmes de fichiers ext3 par défaut.

Il y a un problème avec XFS sur les systèmes EL6 qui est apparu en novembre 2012. J'ai remarqué que mes serveurs affichaient des charges système anormalement élevées, même lorsqu'ils étaient inactifs. Dans un cas, un système non chargé afficherait une moyenne de charge constante de 3+. Dans d'autres, il y avait une bosse de charge 1+. Le nombre de systèmes de fichiers XFS montés semble influencer la gravité de l'augmentation de la charge.

Le système possède deux systèmes de fichiers XFS actifs. La charge est de +2 après la mise à niveau vers le noyau affecté.

En creusant plus profondément, j'ai trouvé quelques discussions sur la liste de diffusion XFS qui indiquaient une fréquence accrue du xfsaildprocessus assis dans l' état STAT D. Les entrées CentOS Bug Tracker et Red Hat Bugzilla correspondantes décrivent les spécificités du problème et concluent qu'il ne s'agit pas d'un problème de performances; seule une erreur dans le rapport de la charge du système dans les noyaux plus récents que 2.6.32-279.14.1.el6 .

WTF?!?

Dans une situation ponctuelle, je comprends que le rapport de charge peut ne pas être un gros problème. Essayez de gérer cela avec votre NMS et des centaines ou des milliers de serveurs! Cela a été identifié en novembre 2012 dans le noyau 2.6.32-279.14.1.el6 sous EL6.3. Les noyaux 2.6.32-279.19.1.el6 et 2.6.32-279.22.1.el6 ont été publiés au cours des mois suivants (décembre 2012 et février 2013) sans modification de ce comportement. Il y a même eu une nouvelle version mineure du système d'exploitation depuis que ce problème a été identifié. EL6.4 est sorti et est maintenant sur le noyau 2.6.32-358.2.1.el6 , qui présente le même comportement.

J'ai eu une nouvelle file d'attente de génération de système et j'ai dû contourner le problème, soit en verrouillant les versions du noyau dans la version antérieure à novembre 2012 pour EL6.3, soit en n'utilisant tout simplement pas XFS, en optant pour ext4 ou ZFS , avec une grave pénalité de performances pour l'application personnalisée spécifique exécutée au sommet. L'application en question s'appuie fortement sur certains des attributs du système de fichiers XFS pour tenir compte des lacunes dans la conception de l'application.

Derrière le site de la base de connaissances paywalled de Red Hat , une entrée apparaît indiquant:

Une charge moyenne élevée est observée après l'installation du noyau 2.6.32-279.14.1.el6. La moyenne de charge élevée est due au fait que xfsaild passe à l'état D pour chaque périphérique formaté XFS.

Il n'y a actuellement aucune résolution pour ce problème. Il est actuellement suivi via Bugzilla # 883905. Contournement du package du noyau installé vers une version inférieure à 2.6.32-279.14.1.

(sauf déclassement des noyaux pas une option sur RHEL 6.4 ...)

Nous avons donc plus de 4 mois dans ce problème, sans véritable correctif prévu pour les versions du système d'exploitation EL6.3 ou EL6.4. Il y a un correctif proposé pour EL6.5 et un correctif source du noyau disponible ... Mais ma question est:

À quel moment est-il judicieux de s'écarter des noyaux et des packages fournis par le système d'exploitation lorsque le responsable en amont a rompu une fonctionnalité importante?

Red Hat a introduit ce bogue. Ils devraient incorporer un correctif dans un noyau d'errata. L'un des avantages de l'utilisation des systèmes d'exploitation d'entreprise est qu'ils fournissent une cible de plate-forme cohérente et prévisible . Ce bogue a perturbé les systèmes déjà en production pendant un cycle de correctifs et réduit la confiance dans le déploiement de nouveaux systèmes. Bien que je puisse appliquer l'un des correctifs proposés au code source , est-ce évolutif? Il faudrait une certaine vigilance pour rester à jour au fur et à mesure que le système d'exploitation change.

Quelle est la bonne décision ici?

• Nous savons que cela pourrait éventuellement être corrigé, mais pas quand.
• La prise en charge de votre propre noyau dans un écosystème Red Hat a son propre ensemble de mises en garde.
• Quel est l'impact sur l'admissibilité au soutien?
• Dois-je simplement superposer un noyau EL6.3 fonctionnel sur des serveurs EL6.4 nouvellement construits pour obtenir la fonctionnalité XFS appropriée?
• Dois-je simplement attendre que cela soit officiellement résolu?
• Qu'est-ce que cela révèle sur le manque de contrôle que nous avons sur les cycles de publication de Linux d'entreprise?
• Compter sur un système de fichiers XFS depuis si longtemps une erreur de planification / conception?

Modifier:

Ce correctif a été intégré à la dernière version du noyau CentOSPlus ( kernel-2.6.32-358.2.1.el6.centos.plus ). Je teste cela sur mes systèmes CentOS, mais cela n'aide pas beaucoup pour les serveurs basés sur Red Hat.

À quel moment est-il judicieux de s'écarter des noyaux et des packages fournis par le système d'exploitation lorsque le responsable en amont a rompu une fonctionnalité importante?

«Au point où le noyau ou les packages du fournisseur sont si horriblement cassés qu'ils ont un impact sur votre entreprise» est ma réponse générale (par coïncidence, il s'agit également du point où je dis qu'il est logique de commencer à chercher des moyens de s'écarter de la relation avec le fournisseur) .

Fondamentalement, comme vous et d'autres l'avez dit, RedHat ne semble pas vouloir corriger cela dans son noyau distribué (pour une raison quelconque). Cela vous laisse à peu près dans la situation d'avoir à faire rouler votre propre noyau (le garder à jour sur les correctifs vous-même, maintenir votre propre package et l'installer sur vos systèmes avec Puppet ou similaire, ou exécuter un serveur de packages Yum ou quoi que ce soit qu'ils utiliser aujourd'hui peut faire référence), ou prendre vos billes et rentrer à la maison.

Oui, je sais que prendre ses billes et rentrer à la maison est souvent une proposition coûteuse - changer de fournisseur de système d'exploitation est une énorme douleur, en particulier dans le monde Linux où les saveurs sont radicalement différentes d'un point de vue administratif.
D'autres options comme passer totalement à CentOS sont également peu attrayantes (parce que vous perdez le support, et vous obtenez toujours le code de RedHat essentiellement construit par quelqu'un d'autre donc vous auriez toujours ce bogue).

Malheureusement, à moins qu'un nombre suffisant de personnes (c.-à-d. "D'énormes entreprises) prennent leurs billes et rentrent chez elles, le vendeur ne se souciera pas tant de visser les gens en expédiant du mauvais code sans le réparer.

Cela a été corrigé ( discrètement ) par Red Hat le 23 avril 2013 dans RHEL kernel-2.6.32-358.6.1.el6 dans le cadre des mises à jour d'errata 6.4 ...

Si vous avez besoin de patcher votre noyau RHEL, vous pouvez le faire vous-même et être officiellement pris en charge sur ce noyau, vous aurez juste besoin qu'ils le certifient.

Il y a des dispositions dans l'accord de support RHEL pour le faire - ISTR vous êtes limité à 1 ou 2 par trimestre ou année mais vous ne vous en souvenez pas avec certitude.