Un système de fichiers est le logiciel employé pour organiser et gérer l'information stockée sur disque ; il assure l'intégrité des données à la condition que les données écrites sur disque sont identiques quand elles sont relues plus tard. En plus des données contenues dans les fichiers, le système de fichier stocke et gère aussi d'autres informations au sujet des fichiers et de lui-même (i.e. informations de date et d'heure, propriétaire, permissions d'accès, taille du fichier, emplacement de stockage sur le disque, etc...) Ces informations sont communément appelées meta-données.

Puisque le système de fichiers essaie autant que possible de travailler de façon asynchrone afin d'éviter les goulots d'étranglement lors des accès au disque, une interruption soudaine de son activité amènerait des pertes de données. Par exemple, considérons le scénario suivant : qu'arriverait-il si votre machine plante quand vous travaillez sur un document qui réside sur le standard de Linux : Ext2FS ? Il y a plusieurs réponses :

Dans ce dernier scénario, les choses peuvent être pires encore si les données écrites sur disques font partie des meta-données, tel le répertoire. Et maintenant, au lieu d'avoir un simple fichier corrompu, c'est un système de fichiers qui l'est, et vous pouvez y perdre un répertoire voire la partition de disque complète.

Le système de fichier standard de Linux, Ext2FS, essaie de prévenir et corriger les cas de corruption de meta-données en effectuant une analyse complète du système de fichier (fsck) lors du démarrage du système. Et comme Ext2FS inclut des copies redondantes des meta-données critiques, il est peu probable que les données soient complètement perdues. Le système s'emploie à savoir où se situent les meta-données corrompues, et soit répare les dommages en recopiant la version redondante, soit efface simplement le ou les fichiers dont les meta-données sont corrompues.

Bien évidemment, plus la taille du système de fichier à vérifier est importante, plus le temps de vérification sera long. Sur des espaces disque de plusieurs giga-octets, cela peut prendre un temps très important de vérifier les meta-données au démarrage.

Et comme Linux commence à être utilisé pour des applications de plus en plus complexes, sur des gros serveurs, et de moins en moins de tolérance pour les arrêts de production, le besoin d'un système de fichier protégeant données et meta-données se fait de plus en plus sentir.

Les systèmes de fichiers journalisés pour Linux sont la réponse à ce besoin.

Nous ne ferons ici qu'une simple introduction aux systèmes de fichiers journalisés. Pour obtenir des informations plus avancées et techniques, reportez-vous à l'article de Juan I. Santos Florido dans la Linux-Gazette n°55. D'autres informations sont disponibles http://freshmeat.net/articles/view/212/.

La plupart des systèmes de fichiers modernes utilisent des techniques de journalisation empruntées au monde des bases de données pour améliorer la reprise sur incident. Les transactions sont écrites séquentiellement sur une partie du disque appelée journal ou log avant de les écrire sur disque à leur place définitive dans le système de fichiers. Les mises en œuvres varient dans le contenu écrit dans le journal. Certaines n'y mettent que les meta-données, alors que d'autres y enregistrent toutes les écritures^[1]

Maintenant, si un plantage survient avant qu'une entrée de journal ne soit validée^[2], les données originales sont toujours sur disque et vous avez uniquement perdu vos dernières modifications. Si le plantage intervient pendant l'update^[3] (i.e. après la validation de l'entrée du journal), l'entrée du journal reflète ce qui aurait dû être fait. Et au ré-amorçage du système, il n'a qu'a rejouer les transactions du journal, et terminer l'update qui a été interrompu.

Dans les deux cas, vous avez des données valides, et non une partition inutilisable. Et comme le temps de reprise sur incident associé à cette approche journalisée, le système est utilisable dans les quelques secondes qui suivent.

Il est aussi important de noter que l'utilisation d'un système de fichiers jounalisé ne rend pas complètement obsolète l'emploi d'un programme de vérification d'intégrité (fsck). Des erreurs matérielles ou logicielles peuvent corrompre de façon aléatoire quelques blocs du système de fichiers, interdisant une récupération grâce au journal de transactions.

Dans ce qui va suivre, nous allons considérer trois systèmes de fichiers journalisés.

Le premier est ext3. Développé par Stephen Tweedie, un des principaux développeurs du noyau Linux, ext3 ajoute la journalisation à ext2. Il est disponible en version alpha à ftp://ftp.linux.org.uk/pub/linux/sct/fs/jfs/

Namesys développe un système de fichiers journalisé du nom de ReiserFS. Il est disponible à http://www.namesys.com/

SGI a sorti le 1^er mai 2001 la version 1.0 de son système de fichiers XFS pour Linux. Vous pouvez le trouver à http://oss.sgi.com/projects/xfs/.

Dans cet article, ces trois solutions seront testées et mesurée au banc d'essai en utilisant deux programmes différents.

Pour obtenir des détails techniques au sujet de ext3, se référer à la publication et à la présentation du Dr Stephen Tweedie.

Le système de fichier ext3 est directement dérivé de son ancêtre ext2. Il a le gros avantage d'être complètement compatible avec ext2 puisqu'il s'agit d'un ext2 avec journalisation. Le désavantage le plus visible est que ext3 ne met pas en œuvre la plupart des caractéristiques avancées des systèmes de fichiers modernes, qui améliorent manipulation des données et compacité de stockage.

ext3 est livré sous la forme d'un patch pour le noyau 2.2.19. Il vous faut donc trouver un noyau linux-2.2.19 sur ftp://ftp.kernel.org/ ou depuis un site miroir. Le patch est disponible depuis ftp://ftp.linux.org.uk/pub/linux/sct/fs/jfs/ ou ftp://ftp.kernel.org/pub/linux/kernel/people/sct/ext3 ou depuis un miroir de ce site.

Vous avez besoin des fichiers suivants :

Copiez le noyau Linux linux-2.2.19.tar.bz2 et ext3-0.0.7a.tar.bz2 dans le répertoire /usr/src, puis en extraire le contenu :

mv linux linux-old
tar -Ixvf linux-2.2.19.tar.bz2
tar -Ixvf ext3-0.0.7a.tar.bz2
cd linux
cat ../ext3-0.0.7a/linux-2.2.19.kdb.diff | patch -sp1
cat ../ext3-0.0.7a/linux-2.2.19.ext3.diff | patch -sp1

Le premier fichier diff est une copie du patch dévermineur noyau de SGI. Le second est le patch de ext3. Maintenant, configurez le noyau, en spécifiant YES à l'option « Enable Second extended fs development code » dans la section « filesystem », puis le construire.

Après la compilation et l'installation du noyau, vous devez construire et installer la suite e2fsprogs :

tar -Ixvf e2fsprogs-1.21-WIP-0601.tar.bz2
cd e2fsprogs-1.21
./configure
make
make check
make install

Et c'est tout. Le point suivant est de construire un système de fichiers ext3 dans une partition. Re-démarrez avec le nouveau noyau. Vous avez maintenant deux options : créer un nouveau système de fichiers, ou en journaliser un existant.

Vous pouvez monter le système de fichier ext3 avec la commande : mount -t ext3 /dev/xxx /mount_dir Puisque ext3 est essentiellement un système de fichier ext2 avec journalisation, un système de fichier ext3 proprement démonté peut être remonté en tant que ext2 sans aucune autre commande.

Pour un survol technique de XFS, se référer à la page linux-XFS du site SGI et aux pages des publications de SGI. Voir aussi la Foire Aux Questions.

XFS est un système de fichiers journalisé pour Linux disponible chez SGI. La technologie est mature, ce qui a été prouvé sur les systèmes Irix en tant qye système de fichiers par défaut pour tous les clients de SGI. XFS est disponible sous LPG (GNU GPL).

XFS Linux 1.0 est disponible pour la version 2.4 du noyau Linux. J'ai essayé le patch pour la version 2.4.2. La première étape est donc d'obtenir le noyau linux-2.4.2 d'un des miroirs de kernel.org. Les patches sont disponibles à ftp://oss.sgi.com/projects/xfs/download/Release-1.0/patches/. Téléchargez-y :

Copiez le noyau Linux linux-2.4.2.tar.bz2 dans /usr/src, renommez le répertoire linux existant en linux-old et extrayez le nouveau noyau :

mv linux linux-old
tar -Ixf inux-2.4.2.tar.bz2

Copiez chacun des patches cités c-dessus et appliquez-les :

zcat patchfile.gz | patch -p1

Configurez ensuite le noyau, en validant les options « XFS filesystem support » (CONFIG_XFS_FS) et « Page buffer support » (CONFIG_PAGE_BUF) dans la section « Filesystem ».

Notez que vous aurez aussi besoin de mettre à jour les utilitaires systèmes dans les versions montrées ici ou les suivantes 

Installez ensuite le nouveau noyau et redémarrez.

Téléchargez maintenant les outils XFS. Cette archive tar contient tout un jeu de commandes pour utiliser XFS, comme mkfs.xfs. Pour les construire :

tar -zxf  xfsprogs-1.2.0.src.tar.gz
cd xfsprogs-1.2.0
make configure
make
make install

Après avoir installé ces commandes, vous pouvez créer un nouveau système de fichiers avec la commande :

# mkfs -t xfs /dev/xxx

Une option importante dont vous aurez peut-être besoin est l'option -f qui forcera la création du nouveau système de fichiers s'il en existe déjà un sur la partition. Bien évidemment, cela détruira toute donnée présente sur cette partition :

mkfs -t xfs -f /dev/xxx

Vous pouvez ensuite monter le système de fichier avec la commande :

mount -t xfs /dev/xxx /mount_dir

Pour les détails techniques au sujet de ReiserFS, référez-vous au site de Namesys et la Foire aux Questions.

ReiserFS est intégré au noyau Linux depuis la version 2.4.1-pre4. Vous devez néanmoins récupérer les outils (i.e. mkreiserfs pour initialiser le système de fichier sur une partition vide, le retailleur, etc.)

La toute dernière version de ReiserFS est disponible en tant que patch envers les noyaux 2.2.x et 2.4.x. J'ai testé la version pour le noyau Linux 2.2.19.

La première étape, comme d'habitude, est d'obtenir le noyau standard linux-2.2.19.tar.bz2 depuis un des miroirs de kernel.org. Récupérez aussi le patch ReiserFS pour 2.2.19

Notez que si vous utilisez la version pour le noyau 2.4, vous aurez aussi besoin de l'archive des utilitaires reiserfsprogs-3.x.0j.tar.gz^[4]

Déballez maintenant l'archive du noyau et le patch. Copiez les archives dans /usr/src et renommez le répertoire linux en linux-old ; puis lancez les commandes :

tar -Ixf linux-2.2.19.tar.bz2
bzcat linux-2.2.19-reiserfs-3.5.33-patch.bz2 | patch -p0

Compilez le noyau en ayant validé le support de ReiserFS dans la section « Filesystem ». Compilez et installez les utilitaires :

cd /usr/src/linux/fs/reiserfs/utils
make
make install

Installez le nouveau noyau et rebootez. Vouz pouvez maintenant créer le nouveau système de fichier ReiserFS, avec la commande suivante :

mkreiserfs /dev/xxxx

et le monter :

mount -t reiserfs /dev/xxx /mount_dir

Pour le test, j'ai utilisé un Pentium III, avec 16 Mo de mémoire et un disque dur de 2 Go, installé avec la distribution Linux RedHat 6.2. Tous les sytèmes de fichiers ont correctement fonctionné chez moi, ce qui m'a fait démarré un petit test de performances pour pouvoir les comparer. Le premier test fut d'arrêter brutalement l'alimentation électrique afin de vérifier la reprise grâce au journal. Tous les systèmes de fichiers ont passé cette phase avec succès, et la machine fut en ordre de marche dans les secondes qui suivirent pour chaque système de fichier.

L'étape suivante est l'analyse de performances en utilisant le programme bonnie++, disponible à http://www.coker.com.au/bonnie++/. Ce programme analyse les accès de type base de données dans un fichier, ainsi que les créations, lectures, et destructions de petits fichiers simulant ainsi les utilisations faites par des programmes tels Squid, INN, ou les programmes utilisant le format Maildir (qmail). La commande utilisée pour lancer le test est :

bonnie++ -d/work1 -s10 -r4 -u0

Elle lance le test en utilisant 10 Mo dans le système de fichiers monté sur le répertoire /work1. Les autres options spécifient la quantité de mémoire utilisée (-r4), et l'utilisateur (-u0, c'est à dire l'administrateur).

Les résultats apparaissent dans les tableaux ci-dessous :

Deux résultats sont montrés par type de test : le débit du système de fichiers (en Ko par seconde) et le temps d'utilisation du processeur (en %). Plus les chiffres de débit sont élevés, meilleurs ils sont pour le système de fichiers. L'inverse est vrai pour le temps processeur.

Ainsi que vous pouvez le voir, ReiserFS remporte haut-la-main la victoire pour la gestion de fichiers (sections « Créations séquentielles » et « Créations aléatoires »), dépassant ses opposants d'un facteur supérieur à 10. De plus, il est quasiment aussi bon que les autres systèmes de fichiers dans les lectures et écritures séquentielles. Il n'y a pas de différence significative entre les autres systèmes de fichiers. XFS est aussi rapide que ext2, et ext3, comme prévu, un peu plus lent que ext2 (qui fait la même chose, la perte de temps dues aux appels systèmes pour la journalisation en moins.)

Le dernier test employé est mongo, un programme disponible sur la page benchmark pour ReiserFS de www.namesys.com, programme que j'ai modifié pour tester les trois systèmes de fichiers journalisés. J'ai inséré dans le script perl mongo.pl les commandes pour monter les systèmes de fichiers XFS et ext3 et pour les formater. Puis j'ai lancé le banc de test.

Le script initialise une partition /dev/xxx, la monte, et fait tourner un certain nombre de processus dans chaque phase : création de fichier, copie, lien symbolique, lectures, état du fichier^[5], renommage, et destruction du fichier. Mongo calcule aussi la fragmentation après les phases de création et de copie :

Vous trouverez les résultats du test sous différentes formes dans le répertoire results :

Les tests furent exécutés comme indiqué dans l'exemple suivant 

mongo.pl ext3 /dev/hda3 /work1 logext3 1

où ext3 doit être remplacé par reiserfs ou xfs pour pouvoir tester les autres systèmes de fichiers. Les autres arguments sont le périphérique à monter où se situe le système de fichier à tester, le point de montage, le nom du fichier où les résultats seront conservés et le nombre de processus à lancer.

Vous trouverez dans les tables suivantes les résultats de l'analyse. Les données correspondent au temps d'exécution, en secondes, la valeur la moins élevée étant la meilleure. Dans le premier tableau, la taille moyenne d'un fichier est de 100 octets, dans le second, 1000 octets, et dans le dernier, 10000 octets.

De ces tableaux, vous pouvez voir que ext3 est souvent plus rapide pour les opérations de type stat, destruction et renommage de fichier, alors que ReiserFS gagne pour les opération de création et de copie. Notez également que les temps d'exécution de ReiserFS sont meilleurs dans le premier cas (petits fichiers) comme prévu dans sa documentation technique.

Il existe actuellement deux systèmes de fichiers journalisés robustes et fiables pour Linux (i.e. XFS et ReiserFS) qui peuvent être utilisés sans crainte. ext3 est toujours en version alpha et peut subir quelque panne. J'ai eu quelques problèmes en utilisant bonnie++ sur ce système de fichiers : le système a enregistré quelques erreurs de la part de la mémoire virtuelle et a détruit l'interpréteur de commandes interactif que j'utilisais.

Au vu des résultats de ce banc d'essai, mon conseil est d'installer ReiserFS à l'avenir (je le ferai sûrement).