Linux : le Kernel a un bug "Lance Armstrong"
Dans son système de fichiers Ext4 qui entraine corruption et pertes de données
Le 2012-10-29 13:17:09, par Hinault Romaric, Responsable .NET
Theodore Ts'o, un développeur du noyau Linux vient de publier des détails sur un bug grave dans le noyau Linux.
Le bug a été découvert par un utilisateur lors d’une mise à jour du noyau de la version 3.6.1 vers la version 3.6.3, qui a entrainé la corruption et la perte de ses données.
Le problème a été qualifié - avec une marque d’humour - de « bug Lance Armstrong » par Theodore Ts'o, en référence au célèbre cycliste déchu pour dopage, du fait du passage de tous les tests de débogage, pourtant il ne se comporte pas comme il devrait.
Après plusieurs analyses, Theodore Ts’o a constaté que le problème était plus ésotérique que ce qu’il estimait au départ, et que les risques de son déclenchement étaient assez limités.
En effet, le problème se produit uniquement lorsque le système s’arrête de façon inappropriée (panne de courant, redémarrage forcé, etc.) alors que celui-ci démonte le système de fichiers, en utilisant la commande umount-I, qui effectue cette opération sans attendre que le système de fichiers cesse d’être occupé.
Des investigations sont encore en cours pour définir avec précision les origines du problème et mettre au point un correctif qui a été rétrogradé à la prochaine branche stable du noyau. Il semblerait que pour l’instant, le bug touche le noyau Linux 3.6.2 et 3.6.3.
Source : LKML.org, Google + de Theodore Ts'o
Le bug a été découvert par un utilisateur lors d’une mise à jour du noyau de la version 3.6.1 vers la version 3.6.3, qui a entrainé la corruption et la perte de ses données.
Le problème a été qualifié - avec une marque d’humour - de « bug Lance Armstrong » par Theodore Ts'o, en référence au célèbre cycliste déchu pour dopage, du fait du passage de tous les tests de débogage, pourtant il ne se comporte pas comme il devrait.
Après plusieurs analyses, Theodore Ts’o a constaté que le problème était plus ésotérique que ce qu’il estimait au départ, et que les risques de son déclenchement étaient assez limités.
En effet, le problème se produit uniquement lorsque le système s’arrête de façon inappropriée (panne de courant, redémarrage forcé, etc.) alors que celui-ci démonte le système de fichiers, en utilisant la commande umount-I, qui effectue cette opération sans attendre que le système de fichiers cesse d’être occupé.
Des investigations sont encore en cours pour définir avec précision les origines du problème et mettre au point un correctif qui a été rétrogradé à la prochaine branche stable du noyau. Il semblerait que pour l’instant, le bug touche le noyau Linux 3.6.2 et 3.6.3.
Source : LKML.org, Google + de Theodore Ts'o
-
PilruMembre éclairéLe problème levé serait lié à des options non activées par défaut dans ext4 : journal_async_commit et journal_checksum.
Bug grave : non, mais bug quand mêmele 29/10/2012 à 16:43 -
ShepardMembre expérimentéSauf erreur de ma part, c'est à cela que sert le système de journalisation: éviter toute perte de données. (Un peu comme le journal dans un SGBDR qui n'est mis à jour que lorsqu'une transaction est validée).
Maintenant, la première phrase de l'article qualifie ce problème de grave, si ça c'est un problème grave, d'autres OS ont du souci à se faire
À bientôt,
Fabianle 29/10/2012 à 16:31 -
transgohanExpert éminentIl y a beaucoup d'OS qui n'impliquent aucune perte de données en cas de redémarrage violent ou panne de courant ? Ce ne sont pas des cas selon moi que l'on peut gérer via programmation donc je me demande quel type de correction ils peuvent apporter.
Edit : j'en viens à me demander si on a pas des attaques de bot quand même sur ce forum... Comment est-il possible de se prendre des -1 en posant une question ? L'être humain serait-il pourri jusqu'à avoir l'habitude convulsive de cliquer sur un pouce baissé dès qu'il en voit un ?le 29/10/2012 à 15:47 -
Joker-ephMembre confirméJ'imagine que la différence entre ce bug et les problèmes liés à un arrêt inopiné reside dans la corruption de tout le système versus la perte des données en cours d'enregistrement.le 29/10/2012 à 23:06
-
Traroth2Membre émériteBen si on récapitule, on a un bug qui provoque effectivement une corruption du système de fichiers, mais pour que ça se produise, il faut que : 1. On active des paramètres qui ne sont pas activés par défaut (ce qui sous-entend quand même que la personne qui le fait est supposé savoir ce qu'elle fait, surtout maintenant que le problème est connu) ; 2. Que le système soit arrêté de manière inopinée, panne de courant, retirer la prise ou un truc du genre.
Vues les conditions à remplir pour que le problème survienne, on peut effectivement dire que, non, ce n'est pas si grave. Même si, oui, il faut corriger le bug.le 30/10/2012 à 10:46 -
Dès lors qu'il y a un arrêt non planifié, tout système a potentiellement un risque de corrompre les données. Ce genre de cas n'est donc pas propre à Linux.
La sauvegarde des données est un point important.le 29/10/2012 à 21:26 -
TabMembre avertiJe retrouve dans ces réponses une logique que je comprends pour ma part.
Peu importe l'OS une opération sur les données stoppée par une panne de courant (entre autre) peut entrainer de la perte de données c'est pour ça que les onduleurs existent parce que le software a ses limites que l'on peut bien comprendre.
Là le bug est sur une option non activée par défaut qui minimiserait les dégâts si j'ai bien compris, ce qui au vu des circonstances nécessaires pour voir le bug n'est pas à qualifier de "grave" à mon sens.le 30/10/2012 à 9:01 -
RachelInactifEst ce que ce bug est présent sur la branche 3.7 ?le 30/10/2012 à 10:16
-
David_gMembre éclairéMoi pour ma part c'est de dire : "Perdre des données ce n'est pas si grave" qui me choque.le 30/10/2012 à 11:03
-
PilruMembre éclairéCe serait même un peu plus tordu que ça (enfin d'après ce que j'ai compris), car ext4, dans ce cas, va utiliser le journal pour remettre le filesystem dans un état cohérent.
Pour que le bug en question puisse survenir, il faut, en plus d'avoir activé des options réputées instables, arrêter brutalement le système pendant une séquence d'arrêt normal. C'est à dire pendant que ext4 vide son journal et avant que le système de fichier soit démonté.le 30/10/2012 à 12:47