Linux : découverte d'un bug sur le système de fichiers EXT4
Qui pourrait causer une importante perte de données
Le 2015-05-23 00:20:46, par Amine Horseman, Expert éminent sénior
Un bug sur Linux a été découvert récemment. Il toucherait le système de fichiers EXT4 RAID et pourrait causer une perte massive de données.
Le bug serait apparu sur les distributions Debian, Fedora et Arch Linux, et ne se serait manifesté que sur les versions 4.x du noyau. Toutefois, Lukas Czerner explique sur la Mailing List du Kernel Linux que le bug pourrait exister depuis la version 3.12 ainsi que toutes les versions stables qui l’ont suivi.
Eric Work qui avait détecté le bug le dimanche dernier avait expliqué sur bugzilla qu’il commença à remarquer la présence d’une corruption de données après une mise à jour du noyau récente sur Fedora 21. « Finalement, le système n'a pas pu démarrer en raison de ce problème de corruption » déclare-t-il, « plus tard, il est avéré que les fichiers corrompus avaient une taille et un horodatage corrects, mais ils étaient remplis de zéros. Parfois des répertoires entiers se vidaient après fsck ».
Le commit qui avait corrigé cette erreur déclarait dans la description que la raison était due à une erreur de calcul de RAID0. Neil Brown, l’auteur de ce commit, explique que « La variable "sector" dans "raid0_make_request()" n’a pas été correctement modifiée par l’appel à "sector_div()" qui modifie son premier argument à la place. Le commit [précèdent] restaurait cette variable après l’appel pour une utilisation ultérieure. Malheureusement la restauration a été effectuée après que la variable "bio" a été avancée ». Cela aurait conduit à ce que la valeur originale et la valeur restaurée de la variable concernée divergent. Pour corriger cette erreur, il aurait suffi de déplacer la ligne responsable de cette modification.
Cependant, ce commit n’a pas encore été intégré dans le code du noyau Linux. En effet, Neil Brown avait écrit hier que « le patch a été ajouté aujourd’hui à mon arbre Git. Je vais l’envoyer demain à Linus alors il devrait apparaître lors de la prochaine RC ». En attendant les utilisateurs qui utiliseraient EXT4 RAID0 pourraient éviter le problème en restaurant le noyau à la version 4.0 le temps que la correction du bug soit intégrée.
Source : Bugzilla, Commit de Neil Brown
Et vous ?
Le bug serait apparu sur les distributions Debian, Fedora et Arch Linux, et ne se serait manifesté que sur les versions 4.x du noyau. Toutefois, Lukas Czerner explique sur la Mailing List du Kernel Linux que le bug pourrait exister depuis la version 3.12 ainsi que toutes les versions stables qui l’ont suivi.
Eric Work qui avait détecté le bug le dimanche dernier avait expliqué sur bugzilla qu’il commença à remarquer la présence d’une corruption de données après une mise à jour du noyau récente sur Fedora 21. « Finalement, le système n'a pas pu démarrer en raison de ce problème de corruption » déclare-t-il, « plus tard, il est avéré que les fichiers corrompus avaient une taille et un horodatage corrects, mais ils étaient remplis de zéros. Parfois des répertoires entiers se vidaient après fsck ».
Le commit qui avait corrigé cette erreur déclarait dans la description que la raison était due à une erreur de calcul de RAID0. Neil Brown, l’auteur de ce commit, explique que « La variable "sector" dans "raid0_make_request()" n’a pas été correctement modifiée par l’appel à "sector_div()" qui modifie son premier argument à la place. Le commit [précèdent] restaurait cette variable après l’appel pour une utilisation ultérieure. Malheureusement la restauration a été effectuée après que la variable "bio" a été avancée ». Cela aurait conduit à ce que la valeur originale et la valeur restaurée de la variable concernée divergent. Pour corriger cette erreur, il aurait suffi de déplacer la ligne responsable de cette modification.
Cependant, ce commit n’a pas encore été intégré dans le code du noyau Linux. En effet, Neil Brown avait écrit hier que « le patch a été ajouté aujourd’hui à mon arbre Git. Je vais l’envoyer demain à Linus alors il devrait apparaître lors de la prochaine RC ». En attendant les utilisateurs qui utiliseraient EXT4 RAID0 pourraient éviter le problème en restaurant le noyau à la version 4.0 le temps que la correction du bug soit intégrée.
Source : Bugzilla, Commit de Neil Brown
Et vous ?
-
Ethan 0x21Membre actif'Tardive' est une hyperbole, en théorie tout bon administrateur Unix&Co qui se respecte, se doit de respecter le principe de précaution sur les serveurs en production vis à vis des mises à jour, ce même principe que des distributions comme Debian appliquent à la lettre avec cependant en contre partie un écosystéme logiciel un peu daté.
Ce n'est pas pour rien que Debian Wheezy utilise un Kernel 3.0.2-4 qui est trés stable et à démontré son efficacité en prod.
Les utilisateurs de distributions comme Fedora ou ArchLinux n'ont pas leur mot à dire car c'est la politique de ces distributions d'inclure assez rapidement les derniéres nouveautés en matiére de kernel afin que leur distribution s'adapte au mieux à une utilisation en mode poste de travail, si Debian est référencé ici c'est certainement vis à vis des utilisateurs qui compiles et installe un noyaux custom et n'utilise pas celui fournis en standard.
Alors ainsi selon moi cette manifestation 'tardive' de ce bogue ne devrait avoir aucun impact pour les utilisateurs/administrateurs un minimum respectieux du principe de précaution à la debian, aprés pour les autres ils sont au courant des risques à vouloir bénéficier des toutes derniéres innovation technologiques.le 23/05/2015 à 1:10 -
pierreactMembre du Club+1 Mais pas top sur l'utilisation memoire, je le vois pas sur un desktop.
Par contre, HAMMER pourrait etre bien sympa de ce cote la...le 25/05/2015 à 12:18 -
frp31Expert éminent séniorregle de base en informatique il est interdit de mettre à jour une machine dont la configuration n'est pas obsolete d'au moins 4/5 versions stables.... (PROD)
je crois que mes pus vieilles versions qui tournent actuellement sont des 2.4.6 linux, des 5.2OpenBSD et des unix proprio....
y'a qu'à la maison que j'ai du récent 5.6OpenBSD et une debian 7.8...le 23/05/2015 à 10:15 -
pierreactMembre du ClubC'est vrai, en tant qu'utilisateur de Debian depuis ~=1998 je n'ai pu que m'en feliciter...
Enfin... Apres, il y a l'integration d'un systeme pas encore stable, encore en developpement comme base du system(d)... Ca c'est tres moyen par contre et ce remet en cause tous ces beaux principes et ces belles paroles.
le 25/05/2015 à 12:17 -
disedorgueExpert éminent séniorBonjour,
Il y a environ 2 ans, où j'étais missionné, il y avait un serveur linux avec une partition sous ext4 qui passait en read-only suite à des problèmes de synchronisation et corruption de données.
A l'époque, en investiguant, j'avais mis en doute l'ext4 et j'ai eu un bras de fer avec l'ingénieur linux pour repasser en ext3.
Après escalade et décharge de responsabilité de l'ingé. linux, repasser en ext3 la partition à résolu le problème que le serveur rencontrait depuis le départ.
Et là, 2 ans plus tard, je constate qu'à priori, ext4 n'est toujours pas stable...
C'est beaule 01/06/2015 à 12:04 -
MarkandMembre éclairéOh mon ZFS sur FreeBSD <3le 25/05/2015 à 10:29
-
TiranusKBXExpert confirméje n'utilise que du RAID 1 je suis sauf ^^le 23/05/2015 à 4:07
-
therev123Membre à l'essaiPour moi c'est pas un problème je suis en mode AHCI et je ne crois pas entreprendre un jour de mettre mon ROG G751JM en RAIDle 23/05/2015 à 5:19
-
Le bug en question est dans le raid logiciel (mdadm), donc pas de rapport avec la configuration AHCI ou RAID du chipset.le 23/05/2015 à 18:39
-
JavaBeanMembre habituéOù est le code source du bug? (Je suis curieux...)le 24/05/2015 à 13:46