Linux : découverte d’un bug sur le système de fichiers EXT4
Linux : découverte d’un bug sur le système de fichiers EXT4
Qui pourrait causer une importante perte de données
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 ?
:fleche: Que pensez-vous de la manifestation tardive de ce bug ?
Principe de précaution de l'OpenSource non appliqué
'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.
La partition ext3 est fiable
La séparation en /home et / permet de faire face à tout problème de partitionnage sensible.
