Autour de Linux

D’ici quelques semaines, Ubuntu 9.04 sortira avec le support du tout nouveau système de fichier ext4. il ne sera pas utilisé par défaut mais vous pourrez le choisir lorsque vous formatterez vos partitions.
Ce nouveau file system a entre autres comme avantage de pouvoir travailler avec des volumes d’1 exaoctet c’est à dire 10¹⁸ octets et des fichiers juqu’à 16 teraoctets (10¹²), de minimiser la fragmentation et de permettre d’avoir plus de 32000 répertoires dans un répertoire. Il y a bien d’autres caractéristiques mais le but de cet article n’est pas de les énumérer. Celle qui justifie cet article et qui semble poser problème est que l’allocation est différée. On parle de allocate-on-flush. En bref, cela veut dire que l’allocation des blocs de données se fait au moment où on écrit sur le disque alors que les autres systèmes de fichiers le font bien plus tôt. Cette mesure permet de minimiser la fragmentation puisque la taille des blocs est déterminée en fonction de la taille réelle du fichier à écrire.

Le problème c’est que plusieurs utlisateurs, testant les versions alpha de Jaunty, ont rapporté des problèmes de perte de données, des fichiers de configuration dont la taille se retrouvait à zéro après un plantage de leur PC. Les programmes dont les fichiers de configuration on été tronqués étaient utilisés lors du plantage.

Avant d’écrire sur le disque, les données sont dans une cache en mémoire. Si vous ouvrez un fichier avec le mode truncate et si un plantage intervient entre le moment où le fichier est ouvert et le moment où les données sont réellement écrites sur le disque, vous perdez les données qui se trouvaient précédemment dans le fichier ainsi que les nouvelles données.

C’est un problème connu et expliqué comme en atteste le commentaire fait par Théodore Ts’o (développeur noyau) pour un rapport de bug.
La cause en est bien souvent des programmes pauvrement écrits. Il ne faut pas ouvrir un fichier en mode truncate puis écrire les données dedans mais créer un fichier temporaire, écrire les données dans ce fichier et finalement le renommer. Cette dernière opération est atomique c’est à dire qu’il ne peut rien arriver pendant l’opération, un lien vers le fichier pointe sur l’ancien ou le nouveau mais il n’y a pas d’état 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.
Avec ext3, les données étaient écrites (flush) sur le disque dans un délai de 5 secondes. Avec ext4, ce délai est indéterminé. Si vous voulez être sûr que vos données sont bien écrites sur le disques il va falloir insérer un fsync() qui va forcer l’écriture sur le disque. La bonne façon de procéder devient donc:

open()    // ouvre un fichier temporaire
write()   // écriture dans le fichier temporaire
fsync()   // flush des données encore en attente
close()   // on ferme le fichier
rename()  // et on renomme le fichier

D’après Theodore Ts’o:

« Notez qu’un close() ne garantit pas que les données sont écrites sur le disque puisque le kernel diffère l’écriture sur le disque. Tous les systèmes de fichiers ne font pas un flush des buffers lorsque le stream est fermé (closed). Si vous devez être sûr que les données sont physiquement écrites sur le disque, utilisez fsync(). »

Si vous comprenez l’anglais, je vous suggère les liens suivant provenant du blog de Theodore Ts’o:

• http://thunk.org/tytso/blog/2009/03/12/delayed-allocation-and-the-zero-length-file-problem/
• http://thunk.org/tytso/blog/2009/03/15/dont-fear-the-fsync/

En conclusion, si vous voulez utiliser ext4, je vous conseille d’attendre un peu que les applications vraiment mal écrite aient été corrigées et puis, un patch est prévu pour le kernel 2.6.30 (ou déjà le 2.6.29 ?) qui devrait minimiser les risques de perte de données.