La journalisation des systèmes de fichiers

Quand bien même GNU/Linux est un système extrêmement fiable, nous ne sommes jamais à l'abri d'un crash, d'une coupure de courant prolongée ou d'une application prioritaire consommant toutes les ressources. Face à ce genre de problème, les conséquences sont toujours plus ou moins les mêmes. Parmi elles, on compte un délai d'attente proportionnel à la taille des disques correspondant à l'exécution de l'utilitaire fsck. Eh bien, réjouissez-vous, le règne de cet utilitaire est terminé, voici venir les systèmes de fichiers journalisés.

Un système de fichiers traditionnel, comme par exemple ext2fs, utilise un mécanisme de cache disque. En effet, si les données étaient écrites sans utilisation du cache, il s'ensuivrait un ralentissement notable du système en général. Le problème du cache, en cas d'interruption brutale du système, repose sur le fait que des informations devant être stockées sur le disque (celles dans le cache à ce moment) aient été perdues. Ce genre de risque est bien entendu valable aussi bien pour les opérations d'écriture mais également d'effacement. Voilà pourquoi il est nécessaire de vérifier l'intégrité du disque suite à ce type de problème. L'utilitaire fsck est alors automatiquement exécuté et le système de fichiers réparé. Le principal défaut de cette procédure réside dans la nécessité de devoir vérifier les systèmes de fichiers dans leur intégralité. Si cela peut être dérangeant pour quelques centaines de méga-octets, cela devient rapidement déprimant avec une cinquantaine de giga-octets d'espace disque.

Pour corriger ce problème, il fallait inventer un nouveau type de système de fichiers utilisant un autre principe de cache. Le principe utilisé pour les systèmes de fichiers journalisés provient du monde des gestionnaires de bases de données. Ces SGBD utilisent en effet un système permettant de différer l'écriture des données à l'aide d'instructions comme BEGIN et COMMIT. Ainsi, il est possible de réduire les opérations d'entrée/sortie sous la forme de transaction. Une transaction ne sera donc effective que lorsque l'ordre COMMIT sera exprimé. Dans le même temps, une trace complète de toutes les transactions est conservée sous la forme d'un journal.

De ce fait, lorsqu'un crash système survient, les manipulations se limitent au parcours du journal des transactions et à la synchronisation du système de fichiers au moment du dernier COMMIT. Il n'est plus nécessaire de vérifier l'intégralité du disque puisque nous savons quelles données était présentes ou non lors de l'incident.

Performances et concepts

La procédure de redémarrage suite à un crash n'est pas la seule raison qui ait conduit au développement de nouveaux systèmes de fichiers. La capacité de stockage des disques est en perpétuelle expansion, tout comme la taille des fichiers. Il n'est plus rare de voir des systèmes équipés de disques dépassant les 50 Go. Autant dire qu'un fsck sur ce genre d'installation risque de prendre un temps considérable. Mais ce genre de capacité provoque également une baisse de performances dans le cadre d'une utilisation normale du système.

En effet, les systèmes de fichiers traditionnels utilisent une cartographie du disque pour repérer les blocs libres et ceux utilisés par des fichiers. Ainsi, lors de l'écriture d'un nouveau fichier sur le disque, cette table est parcourue afin de choisir les blocs à utiliser. Malheureusement, plus le système de fichiers est grand, plus la carte d'allocation des blocs l'est. Il s'en suit un ralentissement lors des opérations sur le disque car le système est obligé de parcourir une carte plus importante à la recherche des informations sur les blocs. De la même manière, la table des fichiers présente sur le disque est également proportionnelle au nombre de fichiers présents. Habituellement, plus le disque est gros, plus il y a de fichiers et donc, plus la table est grande.

Les nouveaux systèmes de fichiers règlent ce problème en utilisant une autre technologie : le B+Tree ou Balanced Tree. Ici, la table d'allocation n'est plus parcourue de manière linéaire mais sous la forme d'une arborescence. En effet, un BTree repose sur une structure sous forme d'arbre où les feuilles (leaf nodes) sont des références (pointeurs) vers les fichiers. De plus, des références internes permettent un parcours plus rapide du catalogue (et non plus table) des fichiers. Ce principe est tiré, encore une fois, des gestionnaires de bases de données où le Balanced Tree est couramment utilisé.

Un Btree ou plus exactement dans le cas d'un système de fichier, un B+Tree, est composé de nodes feuilles regroupés en fonction de leur référencement par un node interne. Vous remarquerez que les groupes de leaf nodes sont également liés entre eux par un pointeur, ce qui permet de garder une possibilité de parcourir les entrées de manière linéaire. Tous les nodes sont indexés par leur nom, qui correspond au nom du fichier. Ainsi, lorsque nous désirons accéder à un fichier, nous cherchons dans le premier niveau de nodes internes. Si notre entrée ne s'y trouve pas, nous utilisons la référence donnée par le dernier node de la recherche (alphabétique croissante). Celle-ci nous renvoie vers un second niveau de node interne où notre recherche échoue encore. En procédant de la même manière, nous arrivons enfin sur les leaf nodes et trouvons l'entrée correspondante à notre fichier.

Comme vous pouvez le constater, cette méthode nécessite beaucoup moins d'effort qu'une recherche séquentielle (linéaire) dans les leaf nodes.

Une autre technique présente dans les nouveaux systèmes de fichiers est l'utilisation des extents (nous ne nous risquerons pas ici à une traduction du terme). L'utilisation des extents est en rapport avec la notion de fragmentation de l'espace disque. Les opérations d'écriture et de libération de blocs créent des "trous" dans le système de fichiers. Ainsi, un système de fichiers traditionnel n'utilisant pas les extents va devoir parcourir la table des blocs à la recherche d'un nombre de blocs correspondant aux données à écrire. Lorsqu'il s'agit de petits fichiers d'une taille inférieure à la taille d'un bloc, ceci n'est pas véritablement un problème. En revanche, lorsque le fichier doit occuper plusieurs centaines de blocs, le système va perdre beaucoup de temps à rechercher et à compter les blocs libres.

L'utilisation des extents permet de réduire ce temps. Les extents sont des référencements de blocs libres contigus. Si vous disposez de 120 blocs contigus libres, l'extent correspondant ne référencera pas les blocs un par un mais le numéro du premier bloc, la taille de l'ensemble et l'offset (décalage par rapport au premier bloc). Il en ressort que la carte des blocs n'est plus nécessaire dans son intégralité et n'est donc plus proportionnelle à la taille du système de fichiers. Seul point noir au tableau, vous perdez tous les bénéfices de ce système avec une grande quantité de fichiers dont la taille représente moins d'un bloc.

Pour conclure cet article, précisons que la décision de passer à un nouveau système de fichiers ne doit pas être prise à la légère. Il s'agit souvent d'une procédure risquée, longue et pénible. Il vous faudra prendre une décision en fonction du matériel que vous possédez et de l'utilisation que vous allez en faire. Mettre à jour un système n'utilisant qu'un malheureux giga-octet n'est sans doute pas une bonne idée, mais c'est à vous de voir ... Enfin, il nous semble nécessaire de préciser deux points importants :