Contenu | Rechercher | Menus

Annonce

Ubuntu-fr vend de superbes t-shirts et de belles clés USB 32Go
Rendez-vous sur la boutique En Vente Libre

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 20/04/2009, à 20:41

mahikeulbody

Le point sur les pertes de données avec ext4

Je démarre ici un nouveau topic car celui ouvert par Blackpegaz n'est pas intitulé correctement par rapport à son problème (parce qu'il a cru tout d'abord que celui-ci était en relation avec ext4).

Pour ceux qui lisent l'anglais, un excellent topic ici : http://linux.slashdot.org/article.pl?si … 19/1730247

A noter aussi :
wikipedia sur ext4 : 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.

Pour les autres, un petit résumé très simplifié:

1) Quand une application écrit des données via le système de fichiers, rien ne lui garantit que ces données seront immédiatement écrites 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 que c'est le moment de les écrire ou jusqu'à ce que l'application lui demande explicitement de le faire par la requête fsync. Beaucoup d'applications ne font pas de fsync, elles laissent faire le système de fichiers.

2) ext3 retient les données au maximum 5 sec. ext4 peut les retenir un temps variable qui peut aller jusqu'à une minute.

3) Dans les deux cas, si le système crashe avant que les données soient écrites sur disque, elles sont perdues. Ce n'est généralement pas très grave: si on a modifié un fichier avec une application et qu'il y a un crash, il "suffit" de refaire la modification à partir du fichier original, c'est juste embêtant mais ça arrive quand même rarement sous linux. Ca peut cependant l'être si on copie ses photos depuis l'appareil photo sur une partition ext4, puis on supprime les photos de l'appareil puis... le système crashe avant que le système de fichiers les ait réellement écrit sur disque (à moins que Nautilus ou Dolphin ne fasse un fsync à la fin de la copie, je ne sais pas ce qu'il en est). Le risque est quasiment nul en ext3 (5 sec max), plus vraisemblable en ext4 (1 min max).

4) Le problème c'est que ext4 ne fait pas qu'augmenter le délai (pour améliorer les performances, optimiser la gestion des SSD et réduite la fragmentation), il travaille autrement que ext3 et là où en cas de crash ext3 ne perd jamais le fichier original, seulement le fichier modifié, ext4 perd les deux : ils deviennt tous les deux des fichiers de longueur 0.

5) Le problème c'est aussi qu'il peut y avoir un problème sans même qu'il y ait un crash : les topics sur le sujet citent que certains enchainements utilisés par certaines applications (tels que créer un fichier puis ensuite le renommer sans faire un fsync entre les deux) peut conduire à des pertes de données en ext4, ce qui n'est pas le cas en ext3.

6) Ceci étant, il n'y a pas à proprement parler de bug sur ext4, son comportement est conforme à ce que dit la norme POSIX. Simplement les applications existantes assument des choses que la norme ne garantit pas, ce qui "passe" en ext3 mais pas en ext4.

7) Vu le tollé que cette affaire a fait (même Linus Torwald s'est engueulé avec le développeur de ext4), le développeur de ext4 a fait un patch réduisant la probabilité d'occurrence du problème, patch backporté sur le noyau utilisé dans jaunty (merci Canonical).

8) Malgré ce patch, j'ai expérimenté des freezes complets et systématiques (plus de souris, ctrl-alt-F1 inopérant) en faisant des rsync sur des dossiers en ext4 après avoir installé digikam (je suis sous gnome). Il faut savoir que la plupart des outils de backup utilisent rsync et que rsync justement ne fait jamais de fsync...

9) Les freezes ont complètement disparu en ajoutant l'option nodelalloc dans les lignes ext4 de fstab. Ceci étant, on dégrade les performances de ext4 et on peut se demander si ça vaut alors la peine de passer en ext4...

Dernière modification par mahikeulbody (Le 20/04/2009, à 21:18)


Core i3 530 - 8 GB mémoire

Hors ligne

#2 Le 20/04/2009, à 21:10

LoseMagnet

Re : Le point sur les pertes de données avec ext4

Donc si je comprend bien :

- le fonctionnement de base de ext4 est conforme aux spécifications;
- un très grand nombre d'application n'utilise pas ext4 correctement
- ext4 a été modifié pour permettre aux applications de fonctionner avec moins de problèmes, mais ça ralentit tout.

Bon, on va rester en ext3 alors...

Le plus gênant est qu'au vu de l'énoncé du problème, il ne semble pas y avoir de solution simple...

Hors ligne

#3 Le 20/04/2009, à 21:29

mahikeulbody

Re : Le point sur les pertes de données avec ext4

Je continue à lire sur le sujet et le discours de certains (dont le développeur) est que beaucoup d'applications ne sont pas bien codées (i.e. ne font pas de fsync là où il faut) parce que en ext3 celui-ci est catastrophique pour les perfs. En ext4, l'impact du fsync sur les perfs est décrit comme bien moindre mais le mal est fait: des tas d'applications sont à corriger.

Ceci étant, d'autres disent que le fsync n'est la plupart du temps pas nécessaire et que le problème vient du fait que sous ext4 l'enchainement création fichier - renommage (enchainement super courant dans presque toutes les applications) sans fsync entre les deux peut très bien être exécuté dans le désordre (c'est conforme à POSIX donc c'est pas un bug...) alors que sous ext3 l'ordre est garanti même sans fsync !


Core i3 530 - 8 GB mémoire

Hors ligne

#4 Le 20/04/2009, à 21:31

Dyocma

Re : Le point sur les pertes de données avec ext4

Oulala... c'est délicat comme information !
Bref, choix difficile pour moi, dois-je rester en ext3...je vais essayer de suivre le sujet.
Que dis Ubuntu ? des infos ?


1 x Ubuntu 16.04 (64bits) - dell inspirion 14 (N3452)
1 x LUbuntu Netbook 16.04 (32bits) - Msi Wind U135
1 x Ubuntu 16.04Lts (64bits) - Lenovo G50-30

Hors ligne

#5 Le 20/04/2009, à 21:38

LoseMagnet

Re : Le point sur les pertes de données avec ext4

mahikeulbody a écrit :

beaucoup d'applications ne sont pas bien codées (i.e. ne font pas de fsync là où il faut)

Il est malheureusement illusoire de penser que les applications vont toutes être corrigées, loin de là hmm
Si la correction repose sur la normalisation des application, on est mal avec ext4 ^^

Hors ligne

#6 Le 20/04/2009, à 21:51

mahikeulbody

Re : Le point sur les pertes de données avec ext4

Pour ceux qui lisent l'anglais, le post DU développeur de ext4 sur ce problème:
http://thunk.org/tytso/blog/2009/03/12/ … e-problem/

Une des conclusions qu'on peut tirer de ce post c'est que l'usage de l'option nodelalloc dans fstab règle le problème au prix d'une dégradation des performances qui devraient cependant rester meilleures qu'avec ext3.

Par ailleurs, 3 patches ont été fait pour résoudre la plupart des cas, et ces patches sont inclus dans Jaunty depuis la beta.

Ceci étant, même avec ces patches, je plantais systématiquement ma Jaunty en faisant un backup avec Back in Time (qui est un client graphique pour rsync, rsync qui justement ne fait pas de fsync) jusqu'à ce que je mette l'option nodelalloc.

Dernière modification par mahikeulbody (Le 20/04/2009, à 21:54)


Core i3 530 - 8 GB mémoire

Hors ligne

#7 Le 20/04/2009, à 23:03

RenZO

Re : Le point sur les pertes de données avec ext4

A mes yeux, l'ext3 n'a pas de mauvaises performances.
On a sûrement plus à gagner en changeant de disque dur, on approche les 100 mo/s en sata actuellement, alors que j'ai 85 mo/s en scsi 15k, les temps changent smile

Hors ligne

#8 Le 20/04/2009, à 23:08

seb24

Re : Le point sur les pertes de données avec ext4

C'est aussi pour ca que exy4 n'est pas par défaut sous Jaunty.


Mini PC NUC avec Ubuntu: ebay

Hors ligne

#9 Le 20/04/2009, à 23:26

mahikeulbody

Re : Le point sur les pertes de données avec ext4

seb24 a écrit :

C'est aussi pour ca que ext4 n'est pas par défaut sous Jaunty.

Je ne pense pas que ce soit la raison car ce choix (ext4 en option et non par défaut) a été fait avant que ce problème monte à la surface.

Pour utiliser ext4 correctement, il faut modifier pas mal d'applis. Mais ces modifications entraineraient des pertes de performances sensibles en ext3 alors à moins de faire pour chaque appli une version ext3 et une autre ext4 (ce qui me parait improbable) les développeurs de ces applis ne changeront rien tant que ext3 sera largement répandu, ce qui risque de continuer longtemps si ext4 fait peur (même s'il ne faut pas exagérer le risque). Aussi certains disent qu'il faut trouver une solution pour ext3 afin que ses performances ne se dégradent pas trop avec les modifications à faire pour ext4 de façon à ce que les développeurs soient moins réticents à modifier leurs applis. Reste à trouver cette solution...


Core i3 530 - 8 GB mémoire

Hors ligne

#10 Le 21/04/2009, à 01:04

Raynor

Re : Le point sur les pertes de données avec ext4

Je crois que la perte de perf des patchs est juste en écriture. Les perfs en écriture ne sont pas critique en utilisation desktop (surtout que linux ne swap pas comme Windows). Par contre ext4 augmente énormément les perfs en lecture, c'est le principal.

Hors ligne

#11 Le 21/04/2009, à 01:40

loopx

Re : Le point sur les pertes de données avec ext4

WaW


Lire tout ce thread, ca fait vraiment peur ... Pourtant, j'ai passé ma gentoo, tuné ma Kubuntu et fait une new install utilisant ext4 ... plus le fait que j'utilise mon disque externe en ext4 ...  Je n'ai eu aucune perte de donnée lié à ext4.

Il est vrai qu'il y a un "souci" ... mais, est-ce aussi grave que vous le dite ? Car a vous entendre, j'aurais du déjà perdre des données ; pas possible autrement. Alors, fausse rumeur ou stress inutile ?


CentOS => tout type de serveur
Ubuntu => tout bon ordinateur
Lubuntu => sur du vieux matos ;-)
Wiki perso : http://pix.noip.me

Hors ligne

#12 Le 21/04/2009, à 06:51

mahikeulbody

Re : Le point sur les pertes de données avec ext4

loopx a écrit :

WaW
Lire tout ce thread, ca fait vraiment peur ... Pourtant, j'ai passé ma gentoo, tuné ma Kubuntu et fait une new install utilisant ext4 ... plus le fait que j'utilise mon disque externe en ext4 ...  Je n'ai eu aucune perte de donnée lié à ext4.

Il est vrai qu'il y a un "souci" ... mais, est-ce aussi grave que vous le dite ? Car a vous entendre, j'aurais du déjà perdre des données ; pas possible autrement.

A nous entendre je ne sais pas, mais à nous lire non ! La perte de données n'arrive que si un crash (ou une coupure de courant) arrive au mauvais moment. Ca n'a pas d'importance pour les nouvelles données (on a juste à recommencer ce qu'on était en train de faire), le problème c'est quand l'application modifie un fichier existant (ce qui arrive très souvent, quand tu édites une photo, un document, etc...), là on perd non seulement la nouvelle version du fichier (pas grave) mais aussi l'ancienne ! (ce qui n'est pas le cas en ext3 où on ne perd que la nouvelle). L'ennui c'est qu'on ne sait pas trop ce qu'on a perdu puisque ça peut aussi affecter des fichiers écrits par des programmes qui tournent en background.
Si tu n'as pas eu de crash/coupure de courant, il est normal que tu n'aies pas perdu de données.


Core i3 530 - 8 GB mémoire

Hors ligne

#13 Le 21/04/2009, à 14:44

Cricket

Re : Le point sur les pertes de données avec ext4

Donc, si par exemple on a souvent des coupures de courant (ou les plombs qui sautent), ext4, ça craint?


XBMC Passion
Ubuntu Lucid 10.04, Carte-mère M3A78-EM HDMI, AMD Athlon-64 X2 4450E 45W @ 2.6Ghz, 1 Go de Ram, CG Nvidia G210 512 Mo Fanless, Disque dur 500 Go. Le tout pour un usage quasi-exclusif en HTPC sous XBMC.
+ Asus EeePC 1001px sous Ubuntu Maverick 10.10

Hors ligne

#14 Le 21/04/2009, à 14:58

loopx

Re : Le point sur les pertes de données avec ext4

Ah oki, uniquement lors de coupure ... 8-)   oui c'est vrai que la ca devient fort lourd. Le problème que j'ai eu avec mon portable viendrais peut être de la. Comment est-ce que cela se présente après le crash ? Fichier existant, mais vide ? Ou fichier non existant ?  J'ai eu des fichier de la lib "glib" qui était vide ... roll  ai du les recopier d'une new install roll   mais bon, c'est réparé smile


CentOS => tout type de serveur
Ubuntu => tout bon ordinateur
Lubuntu => sur du vieux matos ;-)
Wiki perso : http://pix.noip.me

Hors ligne

#15 Le 21/04/2009, à 15:12

Julientroploin

Re : Le point sur les pertes de données avec ext4

... ou en cas de plantage.
... ou en cas de problème matériel

ça fait quand mêm beaucoup je trouve! je suis de moins en moins sûr de vouloir prendre le risque!

Comment est-ce que cela se présente après le crash ?

il travaille autrement que ext3 et là où en cas de crash ext3 ne perd jamais le fichier original, seulement le fichier modifié, ext4 perd les deux : ils deviennt tous les deux des fichiers de longueur 0.


Fixe : Core i5, 8GoRAM, NVidia 9800GT Silent => Ubuntu 18.04
Portable Compaq Presario2158 : AthlonXP-M2400+, 1GoRAM, ATI Radeon mobility320M => Primtux
https://launchpad.net/~julienmbpe

Hors ligne

#16 Le 21/04/2009, à 15:30

mahikeulbody

Re : Le point sur les pertes de données avec ext4

On se retrouve avec des fichiers de longueur 0.

Je rappelle:

en ext3, si vous faites quelque chose qui induit la modification d'un fichier et que ça crashe* avant que ça ait été écrit sur le disque (fenêtre de 5 sec max), vous en êtes quitte pour recommencer ce que vous avez fait après le redémarrage car le fichier avant modif est toujours préservé tant que le fichier modifié n'a pas été réellement copié sur disque.

en ext4, si vous faites quelque chose qui induit la modification d'un fichier et que ça crashe avant que ça ait été écrit sur le disque (fenêtre de 1 min max), vous avez perdu la modification (comme en ext3) mais aussi le fichier tel qu'il était avant la modification !

Si ça tombe sur un fichier système important son absence peut perturber/empêcher le redémarrage. Si ça tombe sur une photo, vous l'avez perdu.

* ou qu'il y a une coupure secteur ou un plantage sévère logiciel qui oblige à rebooter à la sauvage.

Rappel : ce problème n'arrive que pour les applis qui ont pris l'habitude de ne pas forcer l'écriture disque (fsync) avant de fermer le fichier (il y a d'autres cas, c'est un exemple) car ext3 le faisait automatiquement toutes les 5 sec. Le problème c'est qu'il y en a sûrement beaucoup dont des commandes un peu universelles telles que rsync (utilisée dans les outils de backup). Pour des raisons que je ne saurais expliquer ici, le fsync en ext3 est une opération lente (plus qu'en ext4), du coup les développeurs évitaient d'en faire pour ne pas dégrader les performances, d'autant que ça n'induisait pas, contrairement à ext4, de perte de fichiers avant modif.


Core i3 530 - 8 GB mémoire

Hors ligne

#17 Le 21/04/2009, à 15:38

mahikeulbody

Re : Le point sur les pertes de données avec ext4

Julientroploin a écrit :

... ou en cas de plantage.
... ou en cas de problème matériel

ça fait quand même beaucoup je trouve! je suis de moins en moins sûr de vouloir prendre le risque!

Le risque est totalement éliminé si on met l'option nodelalloc dans chaque ligne ext4 de fstab.

(ceci dit, que se passe t-il pour un disque externe ext4 non décrit dans fstab ? ubuntu va le monter automatiquement au branchement mais avec quelles options ?)

Selon le développeur de ext4, même si on perd alors en performance, on reste un peu plus performant qu'en ext3.

L'autre problème plus Jaunty spécific que je décris dans un autre topic "gel complet possible en cas de delete" est également résolu avec nodelalloc (en tout cas chez moi).

Ceci étant, nodelalloc est une option "non-naturelle" car elle inhibe une des améliorations principales de ext4 par rapport à ext3, donc c'est assez dommage même si ça reste à priori un peu plus performant.

Dernière modification par mahikeulbody (Le 21/04/2009, à 15:42)


Core i3 530 - 8 GB mémoire

Hors ligne

#18 Le 28/04/2009, à 19:45

Gadget Boy

Re : Le point sur les pertes de données avec ext4

Uhm, j'ai fait planter Jaunty, avec l'option nodelalloc, en utilisant Back in Time...
Je me suis trompé en mettant cette option ? Dans le fstab, j'ai mis :
UUID=d881ddd7-72e3-4143-ac3e-cbd503f14e45 / ext4 relatime,errors=remount-ro,nodelalloc 0  1

Dernière modification par Gadget Boy (Le 28/04/2009, à 19:46)


Pentium M 1.5Ghz, ATI radeon mobility 9600 --> Lucid

Hors ligne

#19 Le 28/04/2009, à 19:54

loopx

Re : Le point sur les pertes de données avec ext4

Donc, si on a jouer avec des fichiers important, il faut que ca plante exactement 1 minute après modification smile    sinon, on a des problèmes ...


Mmmm, à méditer ce genre de chose big_smile

Il n'existerait pas un système pour sync les disques AVANT plantage complet ? Genre, truc dans le kernel ? (oui, il arrive bien à cracher une stack trace .. pk pas un sync ?)


CentOS => tout type de serveur
Ubuntu => tout bon ordinateur
Lubuntu => sur du vieux matos ;-)
Wiki perso : http://pix.noip.me

Hors ligne

#20 Le 29/04/2009, à 12:34

mahikeulbody

Re : Le point sur les pertes de données avec ext4

Gadget Boy a écrit :

Uhm, j'ai fait planter Jaunty, avec l'option nodelalloc, en utilisant Back in Time...
Je me suis trompé en mettant cette option ? Dans le fstab, j'ai mis :
UUID=d881ddd7-72e3-4143-ac3e-cbd503f14e45 / ext4 relatime,errors=remount-ro,nodelalloc 0  1

Back in Time utilise rsync. rsync peut être amené à faire beaucoup de delete de fichiers. Les release notes de Jaunty indiquent clairement qu'il peut y avoir un problème avec les deletes de masse sous ext4 et recommandent d'attendre avant de passer à ext4.

Ceci dit, moi j'avais un plantage systématique lors du backup (avec Back in Time) et je n'en ai plus* depuis que j'ai mis nodelalloc. Je suppose donc que nodelalloc diminue la probabilité d'avoir le plantage mais ne la supprime pas complètement.

* Bon, en fait si, j'en ai eu 2 sur un PC et 3 sur un autre depuis l'installation de Jaunty (alors que je n'en ai jamais eu sur Intrepid...) mais ce n'est pas dû à ext4 car un des deux PC n'a que ext3


Core i3 530 - 8 GB mémoire

Hors ligne