Discussion :

[Amine Horseman]

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 ?

[Ethan 0x21]

'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.

[TiranusKBX]

je n'utilise que du RAID 1 je suis sauf ^^

[therev123]

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

[frp31]

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...

[Invité]

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.

[JavaBean]

Où est le code source du bug? (Je suis curieux...)

[Markand]

Oh mon ZFS sur FreeBSD <3

[pierreact]

'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.

[pierreact]

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...

[Ethan 0x21]

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.

[MappaM]

À 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 ^^

[disedorgue]

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

[matthius]

La séparation en /home et / permet de faire face à tout problème de partitionnage sensible.