Les systèmes de fichiers journalisés sont en passe de se banaliser sous Linux de nos jours. Les plus connus actuellement sont: reiserfs qui est intégré au noyau depuis 2.4.1; jfs développé par IBM; xfs, système de fichiers originaire de SGI, porté sous Linux par leurs soins; et enfin, ext3 dont nous allons décrire rapidement l'utilisation ici.
L'avantage d'un système de fichiers journalisé est de maintenir en permanence la cohérence des métadonnées [1]. Au reboot après un crash du système (problème matériel, bug du noyau etc), au lieu d'un long et pénible fsck avec ext2, le système va relire le journal, examiner les transactions non terminées, et remettre un système de fichiers sain en quelques secondes. En revanche, la journalisation offre peu de garantie quant au contenu des fichiers eux-même. Si vous étiez en train de modifier un fichier au moment du crash, vous ne pouvez pas toujours récupérer le fichier dans son état avant la modification (et encore moins la version modifiée), tout au moins avec les systèmes de fichiers comme reiserfs, jfs et xfs. Par contre, ext3 est plus sûr de ce côté (en mode par défaut, data=ordered, voir section 5). Pour une description technique des systèmes de fichiers journalisés, nous renvoyons le lecteur aux documents cités dans la section 6.
Ext3 est écrit au départ par Stephen Tweedie. La première version 0.0.1 date de septembre 1999. Depuis, il en est à la version 0.0.7a pour le noyau 2.2.19. Il n'y a pas de développement futur prévu pour les noyaux 2.2 à part les corrections de bugs. En effet, grâce à une nouvelle équipe de hackers, ext3 a été porté sous noyaux 2.4, et a suivi un développement rapide et intensif. Les efforts sont concentrés sur cette branche à l'heure actuelle. Ext3 est considéré comme stable, et est intégré au noyau officiel à partir de la version 2.4.15 (novembre 2001). Il avait fait sa première apparition dans les patchs d'Alan Cox (les séries -ac) à partir de 2.4.7-ac5, et est intégré dans 2.4.8-ac2 (août 2001).
Comparé aux autres systèmes de fichiers journalisés, un des principaux intérêts d'ext3 est sa compatibilité avec le bon vieux ext2 car grosso modo, ext3 = ext2 + journal. Cela veut dire en particulier que:
Vous pouvez convertir vos partitions ext2 actuelles directement en ext3 sans perte de données. Cela est appréciable si vous ne voulez (ou ne pouvez) pas jongler avec la création de nouvelles partitions.
Si vous utilisez occasionnellement un noyau qui ne reconnaît pas ext3, il montera les partitions ext3 en ext2, et les données sur la partition seront exactement les mêmes du point de vue de l'utilisateur. À cela un bémol quand même. Il faut que la partition ext3 soit démontée proprement et que /etc/fstab soit correctement renseigné. En cas de plantage, une partition ext3 ne peut être montée qu'avec un noyau supportant ext3 (ou après un fsck.ext3 sur la partition).
Robustesse, disponibilité et performance d'outils associés (les programmes conçus pour ext2 fonctionnent tels quels pour ext3, ou après quelques modifications);
Vous pouvez consulter l'article de Michael K. Johnson et celui de Daniel Robbins qui décrivent plus précisément les avantages d'ext3. Nous reviendrons sur le réglage des paramètres d'ext3 à la section 5.
Comparaison de performance avec d'autres systèmes de fichiers
Il faut savoir que la journalisation a un certain coût qui se répercute sur la performance du système de fichiers. En clair, ext3 est généralement un peu moins rapide qu'ext2 sur les opérations intensives de création/suppresion de fichiers, même si dans une situation normale, il est équivalent, voire théoriquement supérieur à ext2. Il faut donc peser le pour et le contre en fonction des ses besoins. Comparé aux autres systèmes de fichiers disponibles sous linux comme reiserfs, xfs, jfs, on peut dire ext3 s'en sort très bien, sauf dans le cas extrême de la manipulation simultanée de centaines de milliers de tout petits fichers. Voir les benchmarks réalisés par la société namesys (détentrice de reiserfs). J'ai moi-même réalisé quelques tests. J'insiste sur le fait qu'il faut prendre les benchmarks pour ce qu'ils sont, c'est-à-dire qu'ils ne représentent pas ce qui se passe dans la vie réelle.