Si vous utilisez Linux, et en particulier si vous utilisez une base de données sous Linux, il a été difficile de recommander un système de fichiers autre que le vieux ext3 ces dernières années. Certaines des alternatives qui semblaient intéressantes à un moment donné - jfs, ReiserFS - sont complètement abandonnées à ce stade. Celui qui est presque viable depuis un certain temps maintenant est XFS, à l'origine un projet SGI. Et il est de nouveau à l'honneur cette semaine.
XFS avait souffert d'un certain nombre de problèmes dans le passé. Comme il a été conçu pour un matériel stable, il n'était pas aussi robuste sur du matériel PC bon marché standard au début; une bonne partie a été nettoyée il y a deux ans. Il y avait ce problème étrange avec des fichiers mis à zéro qui effrayaient certaines personnes. Il était traité comme un citoyen de seconde classe dans les distributions Linux orientées métier comme RedHat, vous obligeant à compiler votre propre noyau; même sur le CentOS le moins restrictif, vous deviez effectuer des étapes de configuration étranges pour ajouter la prise en charge de XFS, et le résultat était manifestement non pris en charge. Et comme l'un des premiers systèmes de fichiers à activer et à utiliser de manière agressive les barrières d'écriture, les déploiements étaient vulnérables aux lecteurs et aux contrôleurs qui ne vidaient pas leurs caches lorsqu'on leur demandait de le faire, un problème que vous ne trouvez plus aussi souvent sur le matériel moderne si vous configurez tout va bien (sauf pour les SSD, mais c'est une autre histoire).
Alors pourquoi s'embêter ? Eh bien, la performance est l'une des principales raisons. Je me suis retrouvé à travailler à nouveau avec XFS lorsque j'ai récemment travaillé avec le logiciel gratuit Single Node Edition de Greenplum. Greenplum m'a dit catégoriquement qu'ils ne recommandaient rien d'autre que XFS pour les installations hautes performances, et étant donné les similitudes sous-jacentes avec la communauté PostgreSQL, j'ai pensé que cela valait la peine d'étudier pourquoi c'était un peu plus.
Le timing s'est avéré parfait. L'une des autres limitations d'ext3 est que sur du matériel courant, il ne prend en charge que 16 To de stockage. Étant donné que vous pouvez mettre autant de stockage dans un rack de disques de taille moyenne maintenant, ce n'est clairement pas suffisant pour les systèmes haut de gamme de nos jours, et encore moins dans quelques années. Réalisant cela, RedHat a sérieusement relancé son support pour XFS dans sa distribution de Linux. RHEL 5.4, sorti il y a quelques mois, l'a rajouté en tant que module optionnel pour certains clients. Vous ne pouviez toujours pas installer sur XFS, et même la version CentOS ne prenait pas en charge les installations 32 bits, mais elle faisait clairement de nouveau des pas vers le grand public.
Hier, la première version bêta publique de RHEL6 a été publiée, et XFS est de retour dans l'ensemble des principales fonctionnalités. Il se trouve à côté d'ext4 sur la liste des systèmes de fichiers pris en charge, soulignant sa pertinence pour les grandes installations en particulier. Je peux donc maintenant dire aux gens qu'ils ont un support XFS disponible sous une forme quelque peu approximative dans RHEL/CentOS 5.4, dans l'espoir qu'il s'agit d'un système de fichiers pris en charge de première classe car les systèmes sont mis à niveau vers RHEL6 et ses dérivés à l'avenir, et j'espère que sera fiable.
Avec le support Linux d'entreprise et, par conséquent, le côté stabilité perçue du code XFS enfin sous contrôle, qu'en est-il des performances ? Eh bien, il s'avère que Greenplum avait raison de dire que XFS valait la peine de fonctionner. J'ai pris mon serveur de test et reformaté l'un de ses disques moyennement rapides avec trois combinaisons de système de fichiers/montage différentes : ext3 ordonné, journal ext3 et xfs. Après trois exécutions de bonnie++ 1.96 avec chaque système de fichiers, les résultats que j'ai vus se sont décomposés comme ceci :
- Ext3 commandé :39 à 58 Mo/s en écriture, 44 à 72 Mo/s en lecture
- Journal ext3 :25 à 30 Mo/s en écriture, 49 à 67 Mo/s en lecture
- xfs :68 à 72 Mo/s en écriture, 72 à 77 Mo/s en lecture
Alors que les meilleurs résultats de lecture ext3 approchaient des niveaux similaires à ce dont xfs était capable, en moyenne, il a fait beaucoup mieux. Et les résultats en écriture étaient au moins 25 % meilleurs dans tous les cas. J'ai également aimé le débit plus serré et plus prévisible; J'ai souvent du mal avec les performances incohérentes sur ext3.
Je ne suis normalement pas l'un des premiers à adopter les nouvelles versions de Linux, mais la version bêta de RHEL6 avec prise en charge complète de XFS a remplacé la nouvelle version très décevante d'Ubuntu en haut de ma liste de systèmes d'exploitation à installer ensuite. Ce n'est pas souvent que vous voyez la technologie du système de fichiers avoir une seconde chance d'impressionner, mais XFS semble avoir fait une transition inattendue pour redevenir complètement pertinente, pour l'instant. Je ne sais pas combien de temps cela sera vrai, avec ext4 déjà disponible et btrfs se rapprochant de la qualité de production en atteignant récemment un format de disque stable. Il sera intéressant de voir comment cet ensemble revigoré de choix de systèmes de fichiers sous Linux se déroulera.
