Ext4 et les pertes de données
Ext4, le tout dernier système de fichiers à la mode pour Linux, offre une multitude de nouveautés pour les utilisateurs. Il permet, par exemple, d'accélérer le démarrage ou d'améliorer les performances globales d'un système. D'autres prouesses technologiques sont aussi possibles, comme l'utilisation de volumes de 16 téraoctets ou encore d'avoir plus de 32000 sous-répertoires dans un répertoire.
Mais, il faut garder à l'esprit que celui-ci est encore jeune et il est loin d'être parfait. D'ailleurs, en lisant plusieurs retours d'expérience, on peut apprendre que certaines personnes ont déjà vécu des pertes des données suite à son utilisation.
Le fonctionnement de ext3 et ext4
Pour bien comprendre la vraie problématique, il faut d'abord savoir comment ce système fonctionne. En fait, lorsqu'une application souhaite ajouter des données sur un support de stockage, absolument rien ne lui garantit que celles-ci soient écrites immédiatement sur le disque, pour des raisons de performance. Le plus souvent elles restent en cache un certain temps, jusqu'à ce que le système de fichiers décide de passer à l'action. Cette technique a un nom : allocate-on-flush que l'on peut traduire par allocation différée.
Ce fonctionnement est valable aussi bien pour ext3 que pour ext4. La seule différence est qu'ext3 ne retient les données que 5 secondes au maximum, tandis qu'ext4 peut les retenir un temps variable qui peut aller jusqu'à une minute.
Et c'est là que les choses se compliquent un peu, car si un système Linux plante avant l'écriture sur le disque, les données sont perdues pour toujours. Ce risque qui était limité avec ext3 est donc grandement augmenté aujourd'hui avec l'arrivée d'ext4.
A tout ceci, il faut savoir également qu'ext4 fonctionne un peu différemment par rapport à son prédécesseur (notion d'allocation par extent afin de limiter la fragmentation). En effet, lors d'un crash, ext3 ne perd jamais le fichier original, seulement le fichier modifié. Tandis que Ext4 perd les deux : ils ont alors une taille de 0 octet.
Des solutions ont été données, comme par exemple l'utilisation de l'option nodelalloc dans le fichier /etc/fstab. Celle-ci permet de réduire le temps d'attente avant l'écriture des données. En voici un exemple d'utilisation :
UUID=e3b96b25-xxxxx-xxxxx / ext4 relatime,errors=remount-ro,nodelalloc 0 1
Mais l'utilisation de nodelalloc dégrade un peu les performances de ext4 et, du coup, on peut se demander si cela vaut vraiment le coup de ne plus utiliser ext3.
L'appel système fsync
A noter quand même, il existe une autre méthode où l'application force d'elle-même l'écriture sur un disque sans passer par le cache, grâce à l'appel système fsync. Voici un exemple d'algorithme à utiliser avec ext4 :
1. open() : ouverture du fichier
2. write() : écriture dans le fichier
3. fsync() : écriture des données sur le disque
4. close() : fermeture du fichier
Le problème est qu'au jour d'aujourd'hui, peu de logiciels implémentent cette méthode et préfèrent laisser le système de fichiers gérer cet aspect en utilisant uniquement la fonction close(). Il faudra donc attendre quelques mois, voire années, avant que la plupart des applications libres utilisent ce procédé.
Conclusion
Bref, si vous choisissez d'utiliser ext4, réfléchissez à plusieurs fois et essayez de ne pas y stocker des données sensibles, du moins jusqu'à temps que ce système devienne vraiment fiable.
Créé en 2005, Tux-planet est un site qui a pour ambition de regrouper des articles sur Linux et le monde des logiciels libres. 
23 Commentaires pour "Ext4 et les pertes de données"
Flux des commentaires de cet article Ajouter un commentaireMerci pour ce topo instructif sur le mystérieux ext4 !
Dommage, je voulais réinstaller mon système lors de la sortie de ubuntu 9.04 en le passant en 64 bits et ext4... à réfléchir donc.
Mais Ext4 ne serait-il pas un ext3 avec un temps d'écriture sur disque plus grand?
Je pense pas mais bon...
En tous cas merci pour l'info.
Très bon article, bravo !!
Mais qu'elle genre de crash peuvent provoquer la perte de données ? Une extinction brutale, un problème sur le disque dur ? étrange que l'ext4 soit passé en stable avec autant de défaut
@valentin: Ext4 n'a pas de défaut. Comme expliqué dans ce billet, les applications n'utilisent pas encore la méthode fsync() qui empêcherait ce problème d'arriver.
La balle est dans le camp des développeurs maintenant.
@valentin : une coupure de courrant, un freeze du système, un logiciel instable ..
@Rydgel : oui la balle est dans le camp des développeurs. Sauf que c'est un peut trop facile, il ne faut pas croire que tous les programmes seront récrit comme ça du jour au lendemain. Peut-être que de nouvelles solutions moins coûteuse@manu : seront trouvées entre temps.
@manu : au pire, tu peux faire en sorte que ton homedir soit en ext3 (comme ça tu est sur de pas perdre de données importante) et tu met les fichiers système sur du ext4.
Oui pas bête surtout que je mets tjrs mon /home sur une autre partition. Il n'y aura pas de problème de communication?
@manu : non je pense pas, cela devrait fonctionner.
J'ajouterai que la perte de données peut aussi bien concerner une donnée personnelle (photo par exemple) qu'une donnée système, auquel cas il n'est pas impossible que le système ne redémarre tout simplement pas. J'insiste : on perd aussi la donnée originale (tout dépend bien sûr si l'application ou le bout de système concerné utilise fsync ou pas avant un close ou avant un rename).
En ce qui concerne l'option nodelalloc il me semble avoir lu sur le blog du développeur de ext4 qu'elle résolvait le problème des deux fichiers perdus (original et le modifié), au détriment d'une perte de performance. A vérifier.
Par ailleurs, wikipedia(en) indique qu'il y a des patchs corrigeant le "problème" destinés à être intégrés dans le noyau 2.6.30 mais que Ubuntu les a backporté dans le noyau 2.6.28 de Jaunty.
Est-ce à dire qu'il n'y aurait plus besoin de l'option nodelalloc ? Malheureusement non car un autre problème, qui ne semble arriver que sur Jaunty (avec donc ces patchs backportés) provoque le gel complet (reboot hardware obligatoire) du PC dans certaines circonstances encore mal connues mais que pour ma part je peux reproduire souvent en faisant un rsync entre deux répertoires ext4. Ce dernier problème, qui oblige à maintenir le nodelalloc, est répertorié dans les release notes de Jaunty (du moins il l'était il y a encore deux jours, je ne sais pas s'ils ont trouvé la solution à la dernière minute).
Et malgré nodelalloc j'ai quand même eu, une seule fois, un gel complet.
Même si l'option fsync est une solution pour l'immédiat je ne pense vraiment pas que ça soit une solution à long terme. On ne peut pas demander à tous les développeurs de changer leurs habitudes sous prétexte qu'un système de fichier le nécessite ...et ceux qui sont sous ext3, sous reiserfs ou encore sous zfs ont'il réellement besoin d'une perte de performance (car l'allocate_on_flush a aussi des avantages) sous prétexte que 2 pelés utilisent un ext4 !
Non, je pense que la solution est de régler le problème directement au niveau du noyau. Comme le dit mahikeulbody, des patch vont surement arriver très vite et je ne m'inquieterais pas trop.
Et encore, malgré ce "bug" d'ext4, je ne pense pas qu'il faille tellement s'inquietter. C'est rare qu'un ordinateur freeze et que l'accès au disque plante hormis lors d'une coupure de courant. Perso ça ne m'est plus arrivé depuis très longtemps. Donc je voudrais quand même pas dédramatiser, mais faut pas non plus imaginer qu'on va perdre toutes ses données systématiquement dès qu'on utilise ext4. Mais c'est bien de conscientiser les gens (du moins, ceux pour qui c'est compréhensible)
1) l'option fsync coûte cher en performance en ext3 (bien plus qu'en ext4), c'est pourquoi les développeurs ne changeront pas leurs applis tant que ext3 sera très répandu
2) selon le développeur de ext4, ce n'est pas ext4 en particulier qui nécessite fsync, ce sont les systèmes de fichiers modernes (ca qui inclut celui à venir, le btrfs ou quelque chose comme ça)
3) selon wikipedia (dont je recopie le passage ci-dessous) les patchs en question diminuent fortement les chances de perdre des données, au prix d'une faible perte de performance ; ils "diminuent", ils ne règlent pas. Au vu de ce qu'on peut lire ici et là (et notamment sur le blog du développeur ext4), il y a peu de chances qu'il y ait d'autres patchs car aller plus loin dénaturerait ext4 au point de lui enlever son principal intérêt (en fait ça reviendrait à mettre l'option nodelalloc dans fstab qui ramène ext4 au niveau - ou un peu mieux - de ext4 en terme de performance.
4) selon le développeur, il n'y a pas de bug ext4, ext4 est conforme à Posix. Le problème c'est que les applis sont mal faites
Ce que je retiens de tout ça, c'est que je vais sans doute continuer à utiliser ext4 pour / mais plus /home. En outre je vais garder l'option nodelalloc tant que le problème de gel fatal n'est pas réglé, puis ensuite je l'enlèverai pour améliorer les performances. J'accepte un risque très faible au niveau de / car au pire je réinstalle. Au niveau /home c'est plus délicat car si on ne se rend pas compte qu'on a transformé un fichier perso en fichier de longueur nulle, et qu'ensuite on fait un backup, on perd aussi le fichier sauvegardé (à moins de faire du backup à la Time Machine avec un excellent outil comme Back In Time que je vous conseille).
le passage wikipedia en question (en anglais):
Delayed allocation and potential data loss
The delayed allocation poses some additional risk of data loss in cases where the system crashes before all data has been written to the disk.
The typical scenario is a program that replaces the content of a file, without forcing a write to the disk with fsync. If the system crashes shortly afterwards, it is really undefined what is supposed to happen. However, users have come to expect that the disk holds either the old version or the new version of the file, a behaviour that ext3 would usually yield. Whereas the ext4 code in kernel 2.6.28 will often have truncated the file to zero length before the crash, but not yet written the new version, so that the contents of the file is lost.
Many people find such system behavior unacceptable. A significant issue is that fixing the bug, by using fsync more often, could lead to severe performance penalties on ext3 file-systems mounted with the data=ordered flag (the default on most Linux distributions). Given that both file-systems will be in use for some time, this complicates matters enormously for end-user application developers. In response, Theodore Ts'o has written some patches for ext4 that cause it to limit its delayed allocation in these common cases. For a small cost in performance, this will significantly increase the chance that a version of the file survives the crash.
The new patches are expected to become part of the mainline kernel 2.6.30. Various distributions may choose to backport them to 2.6.28 or 2.6.29, for instance Ubuntu made them part of the 2.6.28 kernel in version 9.04 -- Jaunty Jackalope.[9]
@theClimber : c'est sûr, la solution la plus propre et la plus pérenne est du coté du système et non du coté des applications.
@mahikeulbody : merci pour les précisions. Au passage, le fameux noyau 2.6.30 sera celui de Fedora 11. Ça rassure un peu, sachant qu'ils ont prévu d'utiliser ext4 par défaut pour cette version.
Je viens de passer sur ubuntu 9.04 il y a 2h et avec mon home en ext3 et / et ext4 => aucuns problemes
Très très intéressant tout ça ! Je me posais justement la question quant à mon passage (ou pas) en ext4 et finalement, je pense que je vais rester en 3, pour le moment en tous cas ! :p
Zut j'attendais Ubuntu 9.04 pour réinstaller mon système et tout passer en EXT4, y compris les HDD contenant des données perso (HDD montées en RAID mirroré), j'hésite un peu, du coup, c'est clair que c'est jeune encore comme filesystem ...
On ne dit pas « au jour d'aujourd'hui », nom d'une écrevisse !
Ah merci pour cet article, l'explication est très claire.
Perso je vais rester en ext4, car mon système ne plante jamais et je ne crains pas les coupures de courant (je suis sur un laptop).
J'ai bien fait de reinstaller Ubuntu avec le EXT3 qui marche tres bien car le EXT4 n'est pas tout a fait au point (j'ai eu des bugs, pertes de données apres convertions voire plantage total du systeme)
PS: Le systeme démarre en - de 30 secondes sur ma config Quad Core et 2 Gigas de RAM avec EXT3 tandis qu'avec le EXT4, 10 a 15 secondes de + !
Oui enfin, si tous les programmes utilise fsync(), il n'y aura plus d'interet au cache en écriture puisque plus utilisé et bonjour la chute vertigineuse des performances.
Et puis, un peu facile de faire un changement "bancale" dans un système et dire après," voilà, c'est pas super mais à vous de vous y adapter en refaisant tous vos logiciels". Je suis passé à Linux pour ne plus voir ces méthodes Microsoftienne. Dommage que Linux en arrive là
Ext4 n'est pas encore viable... j'ai le serveur Mandriva d'un client qui bascule les accès SAMBA a ma partition EXT4 en lecture seule après avoir subie une coupure brutale...Un beau bordel ct'e chose....
Bonjour,
A mon sens, le problème de dégradation dont vous parlez :
"En effet, lors d'un crash, ext3 ne perd jamais le fichier original, seulement le fichier modifié. Tandis que Ext4 perd les deux : ils ont alors une taille de 0 octet."
est beaucoup plus grave, fondamentalement, que la perte de modification.
Néanmoins cet élément n'est pas évoqué dans l'article wikipedia (en) ni dans les commentaires.
Ce fonctionnement est il avéré, a-t-il été réglé par des patchs ultérieurs à cette note ?