Linux / ext4, XFS ou Btrfs : différences et critères de choix

Pour choisir entre ext4, XFS et Btrfs, comparez la prise en charge par la distribution, les fonctions nécessaires, le redimensionnement et la récupération. ext4 mérite d’être étudié pour une administration familière et la réduction hors ligne, XFS pour les serveurs à stockage important et entrées-sorties concurrentes, et Btrfs pour les instantanés, la compression et les sommes de contrôle intégrées. Ces critères orientent le choix ; les performances et la facilité d’exploitation dépendent ensuite de votre configuration.

Un système de fichiers organise le contenu des fichiers, leurs noms, emplacements et permissions pour les stocker et les retrouver. Cette comparaison concerne les disques locaux de PC Linux et de serveurs courants. Pour distinguer les couches, consultez les disques, partitions, systèmes de fichiers et montages.

Comparer les fonctions d’ext4, XFS et Btrfs

Les métadonnées décrivent notamment l’emplacement, la taille et les droits des fichiers. La journalisation conserve des informations sur les modifications afin d’aider à retrouver un état cohérent après une interruption. La copie sur écriture, Copy-on-Write ou CoW, écrit les modifications dans un nouvel espace puis met à jour les références. Aucun de ces mécanismes ne constitue à lui seul une sauvegarde indépendante.

Le mot intégré compte : ext4 et XFS peuvent bénéficier d’instantanés fournis par le gestionnaire de volumes logiques, Logical Volume Manager ou LVM, le stockage ou l’hyperviseur. Une copie reflink partageant des blocs, comme sous XFS, n’est pas un instantané complet de tout le système de fichiers. L’absence de sommes de contrôle du contenu ordinaire ne signifie pas non plus une absence de protection des métadonnées.

ext4 : administration familière et réduction hors ligne

ext4, Fourth Extended Filesystem, prolonge la famille ext2 et ext3. Le guide d’installation Debian 13 indique qu’ext4 est le choix par défaut dans la plupart des cas. La disponibilité des outils de création, de contrôle et de secours de votre distribution est un argument pratique ; un choix par défaut ne prouve pas une supériorité universelle de vitesse ou de fiabilité.

Dans son mode habituel data=ordered, ext4 journalise les métadonnées et ordonne l’écriture des données associées avant leur validation dans le journal. Il ne conserve pas une seconde copie de tous les fichiers dans ce journal. La documentation ext4 du noyau Linux distingue les modes de données. Retrouver un système montable après une coupure ne garantit pas que la dernière écriture d’une application a été conservée.

Une distinction utile est la réduction de taille : resize2fs peut agrandir un ext4 monté lorsque le noyau et le format le permettent, mais sa réduction exige un démontage. Réduire la racine nécessite donc généralement un autre environnement de démarrage et une interruption. L’outil ne redimensionne pas la partition sous-jacente.

Si vous prévoyez de redistribuer plus tard l’espace entre système et données, étudiez cette possibilité et son temps d’arrêt avant l’installation. Si le besoin principal est un retour rapide avant mise à jour, ext4 seul ne fournit pas les instantanés : il faut concevoir l’autre couche de stockage et sa procédure de restauration.

XFS : stockage important et accès concurrents

XFS répartit la gestion de l’espace en groupes d’allocation et fait partie des candidats pour de grands ensembles de données et des entrées-sorties parallèles. Red Hat Enterprise Linux, RHEL, 10 l’emploie par défaut pour le stockage local. Le guide RHEL 10 des systèmes de fichiers présente ses fonctions et ses critères de choix. La familiarité de l’équipe avec ses outils de sauvegarde et de secours compte aussi.

L’agrandissement par xfs_growfs s’effectue lorsque le système de fichiers est monté. Le périphérique inférieur doit d’abord fournir l’espace supplémentaire ; agrandir seulement un disque ou un volume logique ne signifie pas que le système de fichiers a suivi. Le manuel xfs_growfs précise le périmètre de cet outil.

La réduction demande une formulation prudente. Les notes de RHEL 10.0 sur les fonctions en aperçu technologique décrivent une réduction limitée à la fin du dernier groupe d’allocation, à condition que la zone retirée ne contienne ni données ni métadonnées allouées. Ce n’est pas une procédure générale pour réduire n’importe quel volume à la taille souhaitée.

Ne basez donc pas une architecture de production sur cette réduction limitée sans vérifier le noyau, les outils et la prise en charge formelle de la distribution. Si un volume plus petit devient nécessaire, préparez plutôt une destination neuve et une restauration vérifiée. Dire que toute réduction XFS est absolument impossible omet les évolutions ; la présenter comme une opération ordinaire prise en charge serait également trompeur.

Un serveur de fichiers volumineux justifie l’évaluation de XFS, sans que la taille des fichiers suffise à conclure. Vérifiez aussi création et suppression de petits fichiers, nombre d’accès simultanés, écritures synchrones et latence sous une charge représentative.

Btrfs : instantanés, compression et contrôle d’intégrité

Btrfs associe CoW, sous-volumes, instantanés, compression transparente et sommes de contrôle des données et métadonnées, comme l’explique son introduction officielle. Une somme de contrôle est une valeur calculée à partir du contenu, comparée lors de la lecture pour détecter un changement inattendu. Fedora utilise Btrfs dans ses éditions et variantes de bureau, selon son guide Btrfs ; cela ne signifie pas une validation de toute configuration serveur.

Un sous-volume est une arborescence pouvant être gérée indépendamment dans le système de fichiers. Un instantané partage initialement les blocs de sa source, puis les modifications consomment de l’espace supplémentaire. La documentation des sous-volumes Btrfs précise que les sous-volumes imbriqués ne sont pas inclus récursivement dans l’instantané du parent.

Choisir Btrfs ne configure pas automatiquement une politique d’instantanés, leur rétention ou un menu de récupération au démarrage. Définissez ce qui doit revenir en arrière, notamment la séparation du système et des données personnelles. Les écritures d’une base nécessitent aussi une procédure de cohérence propre à l’application.

Un instantané sur le même disque ne remplace pas une copie indépendante : la source et l’instantané restent exposés à la perte du support et aux blocs partagés endommagés. Des instantanés conservant d’anciennes données peuvent aussi empêcher de récupérer immédiatement toute la place après suppression de fichiers.

La détection et la réparation sont deux fonctions différentes. btrfs scrub vérifie les sommes et certaines structures ; une réparation de contenu exige une autre copie du bloc, vérifiée comme saine. Dans une configuration contenant un seul exemplaire des données, détecter une corruption ne fournit pas les octets d’origine.

NOCOW, la désactivation de CoW pour les fichiers concernés, implique aussi l’absence de sommes de contrôle pour leurs données. Les métadonnées restent un autre sujet. Ne supposez donc pas que scrub peut choisir une copie de données correcte pour tous les fichiers d’un miroir lorsque ces fichiers n’ont pas de somme de contrôle.

La compression peut réduire l’espace et les entrées-sorties, avec un coût de calcul dépendant des données ; une vidéo ou une archive déjà compressée peut peu en bénéficier. Pour des images de VM ou bases fréquemment réécrites, examinez CoW, fragmentation et conservation des instantanés ensemble. Les options Btrfs expliquent les interactions entre CoW, compression et sommes de contrôle ; ne désactivez pas une fonction en masse à partir d’un simple chiffre de performance.

Pour plusieurs disques, distinguez les profils RAID, Redundant Array of Independent Disks, qui organisent répartition et redondance. La documentation d’introduction qualifie RAID5/6 d’expérimental et d’inadapté à la production. Examinez séparément les états des fonctions Btrfs et la version réellement fournie par votre distribution ; les profils ne présentent pas tous les mêmes garanties.

Relier le choix à votre besoin réel

Ces critères ne sont pas un classement. Un nom Btrfs peu familier ne justifie pas à lui seul de remplacer le choix d’une distribution qui intègre ses outils. À l’inverse, avoir besoin d’un instantané ne suffit pas à choisir un profil ou un mécanisme de restauration sans le tester.

Pour revenir avant une mise à jour, décidez si seuls les fichiers système doivent revenir en arrière ou si les données utilisateur doivent correspondre au même instant. Sur un serveur dont le stockage ne fait que grandir, l’intégration aux outils de l’équipe peut peser davantage que la réduction. Un avantage fonctionnel inutilisé ne compense pas automatiquement le coût d’une migration.

Comparer les performances avec les mêmes garanties

Sur un même SSD, une copie séquentielle, la création de milliers de fichiers et les écritures synchrones d’une base exercent des contraintes différentes. Un test court peut surtout mesurer le cache mémoire. Une conclusion utile décrit le travail et ses conditions au lieu de désigner un système de fichiers toujours plus rapide.

• Utilisez le même support, la même connexion et des conditions comparables de remplissage et d’espace libre.
• Fixez tailles et nombres de fichiers, proportion de lectures et écritures, accès séquentiels ou aléatoires et parallélisme.
• Consignez compression, CoW, instantanés, chiffrement et options de montage ; un changement de fonction modifie la comparaison.
• Conservez les mêmes exigences de durabilité, synchronisation applicative et politique de cache du périphérique. Affaiblir la conservation des données n’est pas un gain de vitesse équivalent.
• Notez noyau et outils, mesurez débit, latence et variation entre répétitions, puis testez sauvegarde et récupération.

Pour un serveur de journaux, simulez ajouts, rotations, compression et sauvegarde simultanés plutôt qu’une seule copie de gros fichier. Évaluez ensemble espace gagné, consommation CPU et latence. Si l’écart est faible, comparez-le au temps d’arrêt, au coût et aux risques nécessaires pour remplacer le format actuel.

Identifier le format actuel et préparer un changement

Interroger les périphériques et le chemin réellement utilisé

Ces commandes lisent les informations des périphériques, montages et capacités sur un système Linux courant. lsblk et findmnt proviennent d’util-linux, et df est généralement fourni par coreutils. Elles ne formatent ni ne convertissent les données :

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
findmnt -T / -o TARGET,SOURCE,FSTYPE,OPTIONS
df -hT /

Dans lsblk, observez la hiérarchie et FSTYPE ; dans findmnt, le format et les options du système de fichiers contenant /. Remplacez / par le véritable répertoire de données pour l’inspecter. Si findmnt affiche xfs pour ce chemin, il appartient à un système de fichiers XFS.

Un disque sans FSTYPE sur sa propre ligne peut contenir des partitions ou volumes logiques dont le format apparaît ailleurs. Dans un conteneur, overlay peut décrire la vue conteneurisée et non le format physique de l’hôte. Une ancienne version de lsblk peut nécessiter MOUNTPOINT au lieu de MOUNTPOINTS. Les manuels lsblk et findmnt donnent les options et conditions de lecture.

Pour Btrfs, btrfs filesystem usage sur le point de montage aide à distinguer données, métadonnées et espace alloué aux périphériques. Consultez les indications Btrfs sur l’espace et le redimensionnement avant de conclure à partir de la seule somme des répertoires ou de df.

Migrer vers une destination neuve et vérifiée

Exécuter un autre mkfs sur le support actuel n’est pas une conversion conservant les données. Une migration générale peut être préparée ainsi, puis adaptée aux outils et couches réellement présents :

1. Identifiez source, format, montage et prise en charge applicative. Créez une copie indépendante et prouvez que vous pouvez la restaurer.
2. Préparez une destination neuve sur un disque ou une zone séparée, en revérifiant son identité et son absence de données à préserver avant tout formatage.
3. Obtenez un état cohérent par arrêt coordonné ou export applicatif, puis restaurez contenu, propriétaires, permissions, ACL, attributs étendus et liens physiques nécessaires. Un outil copiant le contenu ne conserve pas automatiquement toutes ces informations.
4. Vérifiez fichiers et applications au nouveau chemin. Adaptez fstab et les services à l’identifiant UUID du nouveau système de fichiers. Une migration de racine exige aussi une procédure spécifique de démarrage et de chargeur.
5. Après redémarrage, contrôlez montages, droits et services. Conservez source et sauvegarde jusqu’à l’acceptation ; le retour doit aussi traiter les données écrites depuis la bascule, sans les abandonner silencieusement.

Pour un redimensionnement sans changement de format, l’ordre des couches reste essentiel : on agrandit généralement le stockage inférieur avant le système de fichiers, et on réduit d’abord le système de fichiers lorsque cette réduction est prise en charge. Btrfs ne modifie pas automatiquement la table des partitions. Chiffrement, LVM et RAID imposent leurs procédures propres ; ce principe ne constitue pas une commande universelle de redimensionnement.

Les outils de réparation ne sont pas interchangeables. Distinguez e2fsck, xfs_repair et les outils Btrfs, et consultez les précautions des contrôles avec fsck. En particulier, la documentation btrfs check déconseille --repair sans l’avis d’un développeur ou d’une personne expérimentée. Préservez les données et choisissez une procédure adaptée au diagnostic avant une réparation modifiant le support.