Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Linux : découverte d'un bug sur le système de fichiers EXT4
Qui pourrait causer une importante perte de données

Le , par Amine Horseman

0PARTAGES

6  0 
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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Ethan 0x21
Membre actif https://www.developpez.com
Le 23/05/2015 à 1:10
'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.
5  0 
Avatar de pierreact
Membre du Club https://www.developpez.com
Le 25/05/2015 à 12:18
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...
3  0 
Avatar de frp31
Expert éminent sénior https://www.developpez.com
Le 23/05/2015 à 10:15
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...
2  0 
Avatar de pierreact
Membre du Club https://www.developpez.com
Le 25/05/2015 à 12:17
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.
2  0 
Avatar de disedorgue
Expert éminent https://www.developpez.com
Le 01/06/2015 à 12:04
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
2  0 
Avatar de Markand
Membre confirmé https://www.developpez.com
Le 25/05/2015 à 10:29
Oh mon ZFS sur FreeBSD <3
1  0 
Avatar de TiranusKBX
Expert confirmé https://www.developpez.com
Le 23/05/2015 à 4:07
je n'utilise que du RAID 1 je suis sauf ^^
0  0 
Avatar de therev123
Membre à l'essai https://www.developpez.com
Le 23/05/2015 à 5:19
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
0  0 
Avatar de lecbee
Membre du Club https://www.developpez.com
Le 23/05/2015 à 18:39
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.
0  0 
Avatar de JavaBean
Membre habitué https://www.developpez.com
Le 24/05/2015 à 13:46
Où est le code source du bug? (Je suis curieux...)
0  0