J’ai récemment été confronté à une incompatibilité ext4 : un système de fichiers récent refusait de se monter sur un serveur avec une version de Linux plus ancienne. TL;DR : il existe des possibilités de conversion ou de formatage pour garantir cette compatibilité.
Imaginez le scénario suivant : vous remplissez un disque dur de serveur localement dans le but d’aller l’installer par la suite dans un serveur quelconque. Pour cela vous utilisez le système de fichiers ext4 comme d’habitude, qui existe depuis 2008 et qui ne devrait donc pas poser trop de soucis.
Seul problème : le FS ext4 a été formaté sous Debian 9.3 (Linux 4.9.0-4 et e2fslibs 1.43.4-2) alors que le serveur cible tourne sous Debian 6 (Linux 2.6.32-5 et e2fslibs 1.41.12-4stable1) ou encore RHEL 6.10 (Linux 2.6.32-754 et e2fsprogs-libs-1.41.12-24)
Première incompatibilité : l’attribut metadata_csum
Lors du montage si vous obtenez le message d’erreur (ou de log) suivant, c’est l’option metadata_csum de ext4 qui est en cause (plus d’informations). Cette option est apparue dans Linux 3.6 et elle n’est pas reconnue avec les versions antérieures.
|
1 |
EXT4-fs (sdf1): couldn't mount RDWR because of unsupported optional features (400) |
On peut convertir un FS ext4 existant dans le but de le rendre compatible avec un système plus ancien. Bien entendu, les opérations de conversion doivent se faire sur un système récent.
ll faut commencer par faire une vérification disque, puis désactiver l’option en question.
|
1 2 3 4 |
# fsck.ext4 -f -C0 /dev/sdX1 [...] # tune2fs -O ^metadata_csum /dev/sdX1 [...] |
Seconde incompatibilité : le journal 64 bits
Le message d’erreur suivant indique un problème de compatibilité du journal JBD utilisé par ext4. Plus d’informations sur le wiki ext4.
|
1 2 |
JBD: Unrecognised features on journal EXT4-fs (sdf1): error loading journal |
Ce message n’est pas très parlant mais une lecture des informations du superblock avec dumpe2fs -h /dev/sdX1 montre que le journal JBD a la fonctionnalité journal_64bits et ext4 a la fonctionnalité 64bit.
La désactivation de l’option ext4 64bit ne se fait pas comme précédemment comme on peut le voir avec la tentative infructueuse ci-dessous.
|
1 2 3 4 5 6 |
# tune2fs -O ^64bit 1G tune2fs 1.43.4 (31-Jan-2017) Please run e2fsck -f on the filesystem. Après avoir lancé e2fsck, veuillez lancer « resize2fs -s 1G » » pour désactiver le mode 64-bits. |
Il faut plutôt procéder comme suit. C’est une opération irréversible, il ne sera plus possible d’activer 64bit à nouveau.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
# e2fsck -f -C0 /dev/sdX1 e2fsck 1.43.4 (31-Jan-2017) Passe 1 : vérification des i-noeuds, des blocs et des tailles Passe 2 : vérification de la structure des répertoires Passe 3 : vérification de la connectivité des répertoires Passe 4 : vérification des compteurs de référence Passe 5 : vérification de l'information du sommaire de groupe 1G : 4086/64000 fichiers (0.3% non contigus), 251904/256000 blocs # resize2fs -s /dev/sdX1 resize2fs 1.43.4 (31-Jan-2017) Conversion du système de fichiers en 32 bits. Le système de fichiers sur 1G a maintenant une taille de 256000 blocs (4k). |
Comment éviter cette mésaventure
A mon avis une manière très simple de soumettre des données à un système obsolète est d’employer ext3 au lieu de ext4. Cette version du filesystem a été introduite en 2001 et elle devrait normalement avoir été figée plus tôt au niveau de ses fonctionnalités.
Si toutefois vous souhaitez formater un périphérique en ext4 sans metadata_csum et sans 64bit, pour garantir sa compatibilité avec un système obsolète, vous pouvez le faire ainsi. De cette manière aucune conversion n’est requise sur un système de fichiers rempli.
|
1 |
# mkfs.ext4 -O ^metadata_csum,^64bit /dev/sdX1 |
Pour finir, il est bien évident que la mise à jour des serveurs et des appliances (routeurs, NAS, etc) est importante pour utiliser les dernières versions de paquets qui comprennent très souvent des correctifs de sécurité. Si vous utilisez RedHat Entreprise Linux 6.10, sachez que sa date de fin de support se rapproche (fin 2020) donc une mise à jour de l’OS ou une migration est à envisager. Et pour cela, peut-être qu’il vous sera utile de lire et d’écrire sur un disque dur ext4 formaté récemment ?
L’erreur ici est plutôt d’utiliser un Debian 6 (et un noyau 2.6…) alors que Debian est déjà à la version 9 et Linux à la fin de sa version 4…
C’est vrai qu’il est étonnant qu’il y ait une telle incompatibilité, ceci dit.
C’est bien vrai ! On ne fait pas toujours ce qu’on veut chez les clients 🙂
hélas.. d’ailleurs je dev actuellement avec Ibm Rad en java 6 et avec Cvs.. Je veux mourrir.
Descendante plutôt, non ? Si c’est compatible quand les numéros de version augmentent, compatibilité ascendante. Si c’est rétro-compatible, compatibilité descendante.
Et une incompatibilité ascendante sur un FS, ce serait vraiment catastrophique (je mets à jour mon système et il ne lit plus mon disque dur…).
Je qualifie la compatibilité du sujet « filesystem ext4 » par rapport au noyau Linux comme suit.
Ascendante : je monte un nouveau ext4 sur un ancien système.
Descendante (rétrocompatibilité) : je monte un ancien ext4 sur un nouveau système (ou un système mis à jour).
Donc pour un filesystem ext4 donné, quand les numéros de version du kernel augmentent, la compatibilité ascendante n’est pas certaine.
Par analogie avec le mode des consoles de jeu, la rétrocompatibilité consiste bien à mettre un ancien média (cartouche, disque, etc) dans un nouveau système.