{"id":450,"date":"2009-03-30T10:43:29","date_gmt":"2009-03-30T08:43:29","guid":{"rendered":"http:\/\/linux.leunen.com\/?p=450"},"modified":"2009-03-30T10:43:29","modified_gmt":"2009-03-30T08:43:29","slug":"risque-de-perte-de-donnees-avec-ext4","status":"publish","type":"post","link":"https:\/\/www.leunen.com\/linux\/2009\/03\/risque-de-perte-de-donnees-avec-ext4\/","title":{"rendered":"Risque de perte de donn\u00e9es avec ext4?"},"content":{"rendered":"

D’ici quelques semaines, Ubuntu 9.04 sortira avec le support du tout nouveau syst\u00e8me de fichier ext4<\/em>. il ne sera pas utilis\u00e9 par d\u00e9faut mais vous pourrez le choisir lorsque vous formatterez vos partitions.
\nCe nouveau file system a entre autres comme avantage de pouvoir travailler avec des volumes d’1 exaoctet c’est \u00e0 dire 1018<\/sup> octets et des fichiers juqu’\u00e0 16 teraoctets (1012<\/sup>), de minimiser la fragmentation et de permettre d’avoir plus de 32000 r\u00e9pertoires dans un r\u00e9pertoire. Il y a bien d’autres caract\u00e9ristiques mais le but de cet article n’est pas de les \u00e9num\u00e9rer. Celle qui justifie cet article et qui semble poser probl\u00e8me est que l’allocation est diff\u00e9r\u00e9e. On parle de allocate-on-flush. En bref, cela veut dire que l’allocation des blocs de donn\u00e9es se fait au moment o\u00f9 on \u00e9crit sur le disque alors que les autres syst\u00e8mes de fichiers le font bien plus t\u00f4t. Cette mesure permet de minimiser la fragmentation puisque la taille des blocs est d\u00e9termin\u00e9e en fonction de la taille r\u00e9elle du fichier \u00e0 \u00e9crire.<\/p>\n

Le probl\u00e8me c’est que plusieurs utlisateurs, testant les versions alpha de Jaunty<\/em>, ont rapport\u00e9 des probl\u00e8mes de perte de donn\u00e9es, des fichiers de configuration dont la taille se retrouvait \u00e0 z\u00e9ro apr\u00e8s un plantage de leur PC. Les programmes dont les fichiers de configuration on \u00e9t\u00e9 tronqu\u00e9s \u00e9taient utilis\u00e9s lors du plantage.<\/p>\n

Avant d’\u00e9crire sur le disque, les donn\u00e9es sont dans une cache en m\u00e9moire. Si vous ouvrez un fichier avec le mode truncate et si un plantage intervient entre le moment o\u00f9 le fichier est ouvert et le moment o\u00f9 les donn\u00e9es sont r\u00e9ellement \u00e9crites sur le disque, vous perdez les donn\u00e9es qui se trouvaient pr\u00e9c\u00e9demment dans le fichier ainsi que les nouvelles donn\u00e9es.<\/p>\n

C’est un probl\u00e8me connu et expliqu\u00e9 comme en atteste le commentaire<\/a> fait par Th\u00e9odore Ts’o (d\u00e9veloppeur noyau) pour un rapport de bug.
\nLa cause en est bien souvent des programmes pauvrement \u00e9crits. Il ne faut pas ouvrir un fichier en mode truncate<\/em> puis \u00e9crire les donn\u00e9es dedans mais cr\u00e9er un fichier temporaire, \u00e9crire les donn\u00e9es dans ce fichier et finalement le renommer. Cette derni\u00e8re op\u00e9ration est atomique c’est \u00e0 dire qu’il ne peut rien arriver pendant l’op\u00e9ration, un lien vers le fichier pointe sur l’ancien ou le nouveau mais il n’y a pas d’\u00e9tat entre les deux. Donc si votre PC plante, sur le disque vous aurez soit l’ancien fichier, soit le nouveau mais en aucun cas un fichier vide.
\nAvec ext3<\/em>, les donn\u00e9es \u00e9taient \u00e9crites (flush) sur le disque dans un d\u00e9lai de 5 secondes. Avec ext4<\/em>, ce d\u00e9lai est ind\u00e9termin\u00e9. Si vous voulez \u00eatre s\u00fbr que vos donn\u00e9es sont bien \u00e9crites sur le disques il va falloir ins\u00e9rer un fsync()<\/em> qui va forcer l’\u00e9criture sur le disque. La bonne fa\u00e7on de proc\u00e9der devient donc:<\/p>\n

\r\nopen()    \/\/ ouvre un fichier temporaire\r\nwrite()   \/\/ \u00e9criture dans le fichier temporaire\r\nfsync()   \/\/ flush des donn\u00e9es encore en attente\r\nclose()   \/\/ on ferme le fichier\r\nrename()  \/\/ et on renomme le fichier\r\n<\/pre>\n
D’apr\u00e8s Theodore Ts’o:<\/p>\n
\u00ab\u00a0Notez qu’un close() ne garantit pas que les donn\u00e9es sont \u00e9crites sur le disque puisque le kernel diff\u00e8re l’\u00e9criture sur le disque. Tous les syst\u00e8mes de fichiers ne font pas un flush des buffers lorsque le stream est ferm\u00e9 (closed). Si vous devez \u00eatre s\u00fbr que les donn\u00e9es sont physiquement \u00e9crites sur le disque, utilisez fsync().\u00a0\u00bb<\/p><\/blockquote>\n
Si vous comprenez l’anglais, je vous sugg\u00e8re les liens suivant provenant du blog de Theodore Ts’o:<\/p>\n