IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Linux Discussion :

Linux : découverte d’un bug sur le système de fichiers EXT4


Sujet :

Linux

  1. #1
    Expert éminent sénior

    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2014
    Messages
    194
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : septembre 2014
    Messages : 194
    Points : 12 283
    Points
    12 283
    Par défaut 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 ?

    Que pensez-vous de la manifestation tardive de ce bug ?

  2. #2
    Membre actif Avatar de Ethan 0x21
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    août 2006
    Messages
    120
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : août 2006
    Messages : 120
    Points : 261
    Points
    261
    Par défaut 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.

  3. #3
    Expert confirmé
    Avatar de TiranusKBX
    Homme Profil pro
    Développeur C, C++, C#, Python, PHP, HTML, JS, Laravel, Vue.js
    Inscrit en
    avril 2013
    Messages
    1 476
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur C, C++, C#, Python, PHP, HTML, JS, Laravel, Vue.js
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2013
    Messages : 1 476
    Points : 4 746
    Points
    4 746
    Billets dans le blog
    6
    Par défaut
    je n'utilise que du RAID 1 je suis sauf ^^
    Rien, je n'ai plus rien de pertinent à ajouter

  4. #4
    Membre à l'essai
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    juin 2012
    Messages
    104
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Développeur de jeux vidéo

    Informations forums :
    Inscription : juin 2012
    Messages : 104
    Points : 17
    Points
    17
    Par défaut
    Pour 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 RAID

  5. #5
    Expert éminent sénior Avatar de frp31
    Homme Profil pro
    Ingénieur systèmes et réseaux
    Inscrit en
    juillet 2006
    Messages
    5 196
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur systèmes et réseaux
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juillet 2006
    Messages : 5 196
    Points : 12 262
    Points
    12 262
    Par défaut
    regle 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...

  6. #6
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par therev123 Voir le message
    Pour 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 RAID
    Le bug en question est dans le raid logiciel (mdadm), donc pas de rapport avec la configuration AHCI ou RAID du chipset.

  7. #7
    Membre habitué
    Homme Profil pro
    Développeur indépendant
    Inscrit en
    juillet 2011
    Messages
    75
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur indépendant

    Informations forums :
    Inscription : juillet 2011
    Messages : 75
    Points : 163
    Points
    163
    Par défaut
    Où est le code source du bug? (Je suis curieux...)

  8. #8
    Membre éclairé
    Homme Profil pro
    Développeur C++
    Inscrit en
    octobre 2008
    Messages
    236
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Développeur C++

    Informations forums :
    Inscription : octobre 2008
    Messages : 236
    Points : 691
    Points
    691
    Par défaut
    Oh mon ZFS sur FreeBSD <3

  9. #9
    Membre du Club
    Inscrit en
    novembre 2003
    Messages
    40
    Détails du profil
    Informations forums :
    Inscription : novembre 2003
    Messages : 40
    Points : 68
    Points
    68
    Par défaut
    Citation Envoyé par Ethan 0x21 Voir le message
    '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.
    C'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.

  10. #10
    Membre du Club
    Inscrit en
    novembre 2003
    Messages
    40
    Détails du profil
    Informations forums :
    Inscription : novembre 2003
    Messages : 40
    Points : 68
    Points
    68
    Par défaut
    Citation Envoyé par Markand Voir le message
    Oh mon ZFS sur FreeBSD <3
    +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...

  11. #11
    Membre actif Avatar de Ethan 0x21
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    août 2006
    Messages
    120
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : août 2006
    Messages : 120
    Points : 261
    Points
    261
    Par défaut
    Citation Envoyé par pierreact Voir le message
    C'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.
    Si tu parles de la Debian Jessie avec le systemd, je suis d'accord avec toi, c'est une honte à un quasi sans faute de cette distribution.
    J'ai pu directement mettre la toute premiére release de la Wheezy en prod sans aucuns problémes, ce dont je ne risquerai même pas avec la derniére
    a cause des bogues relatifs au systemd ou pas d'ailleur ( des crashs aléatoires de certaines applications, des arrêt systémes digne des 90's (system halted) halt =/= poweroff, etc...)

    Aprés il faut admettre que le changement de sysvinit à systemd n'est pas une mince affaire, il y a pleins d'éléments à prendre en considération, mais
    il aurait logiquement fallut retarder le passage de unstable à stable qui est prématuré à mon sens.

  12. #12
    Candidat au Club
    Inscrit en
    juin 2005
    Messages
    5
    Détails du profil
    Informations forums :
    Inscription : juin 2005
    Messages : 5
    Points : 4
    Points
    4
    Par défaut
    À voir le correctif ce bug n'est pas lié à EXT4 mais au module MD de RAID 0 et est donc la couche en dessous du système de fichier. Tous raid 0 créés avec mdadm et compagnie serait buggué indépendament du système de fichier utilisé.

    La solution serait plutôt d'utiliser LVM qui utilisera le device mapper et non MD pour construire un raid 0. dmsetup devrait permettre de récupérer un raid existant sans utiliser MD, mais ca ne serait pas une mince affaire et plutôt dangereux ^^

  13. #13
    Expert éminent sénior Avatar de disedorgue
    Homme Profil pro
    Ingénieur intégration
    Inscrit en
    décembre 2012
    Messages
    3 923
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur intégration
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : décembre 2012
    Messages : 3 923
    Points : 11 518
    Points
    11 518
    Par défaut
    Bonjour,
    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 beau
    Cordialement.

  14. #14
    Inactif  

    Homme Profil pro
    Écrivain public, Économiste et Programmeur Free Pascal
    Inscrit en
    août 2005
    Messages
    350
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Écrivain public, Économiste et Programmeur Free Pascal
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2005
    Messages : 350
    Points : 943
    Points
    943
    Billets dans le blog
    40
    Par défaut La partition ext3 est fiable
    La séparation en /home et / permet de faire face à tout problème de partitionnage sensible.

Discussions similaires

  1. Manipuler l'héritage des droits sur le système de fichier
    Par piotrr dans le forum Framework .NET
    Réponses: 0
    Dernier message: 19/06/2009, 10h08
  2. Interagir sur un système linux avec une connexion telnet en JAVA
    Par grandthor dans le forum Général Java
    Réponses: 9
    Dernier message: 17/04/2009, 01h47
  3. Réponses: 1
    Dernier message: 14/08/2008, 10h48
  4. [ODBC] Utilisation d'une base Access sur un système Linux
    Par tarah01 dans le forum PHP & Base de données
    Réponses: 2
    Dernier message: 01/06/2007, 11h53
  5. [xp] problème étrange sur le système de fichiers
    Par Huntress dans le forum Windows XP
    Réponses: 4
    Dernier message: 05/03/2006, 21h15

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo