Système de fichiers journalisé

Le système de fichiers journalisés est un système de fichiers[tolérant/résistant aux pannes] qui permet d'assurer l'intégrité des données en cas de problème matériel, de panne de courant (ou Hot-swap|débranchement à chaud) ou d'arrêt brutal du système. Cette fonctionnalité est assurée par la tenue d'un Journal (système de fichiers) référençant les opérations d'écriture sur le support physique avant que ce dernier ne soit réellement mis à jour. Le système de fichiers doit permettre une reprise d'activité à la suite d'une coupure brutale, telle un arrêt électrique. Les métadonnées doivent alors rester cohérentes et à jour. La journalisation permet d'optimiser le contrôle d'intégrité du système de fichiers, réduisant ainsi le temps de redémarrage du système, critère important dans les environnements qui ont besoin d'une [haute disponibilité].

Objectifs

La journalisation du système de fichier assure la cohérence des données en utilisant un journal. Ce journal est un fichier spécial qui enregistre les changements destinés au système de fichier, dans une mémoire circulaire. À intervalles réguliers, le journal est appliqué sur le système de fichier. Si une interruption électrique intervient, le journal peut être utilisé comme point de départ afin de récupérer les informations non sauvegardées, et ainsi assurer l'intégrité des données du système de fichier.

Méthodes

Journaux physiques

Le journal physique enregistre les modifications de données sur le support avant que celles-ci soient opérées. Les entrées contenues dans ce journal comprennent les données à écrire, ainsi qu'une somme de contrôle, afin d'assurer l'intégrité de celles-ci. Ceci permet d'éviter d'écrire des données pour lesquelles l'entrée du journal est incomplète, en cas de rejeu principalement. Cette méthode pénalise les performances, car chaque écriture nécessite une double écriture sur le support physique, une pour le journal, et une pour les données effectives. Elle est néanmoins acceptée en raison de la garantie de la cohérence des données qu'elle permet.

Journaux logiques

Le journal logique ne stocke que les métadonnées, sacrifiant la tolérance aux pannes pour de meilleures performances. Il permet lui aussi le rejeu des opérations, mais peut lier des métadonnées journalisées à des données non journalisées, causant ainsi une corruption des données.

Écritures à risque

Le cache d'écriture de la plupart des systèmes d'exploitation trie les opérations d'écriture en fonction de leur taille afin de maximiser les performances. Pour éviter un déséquilibre entre les métadonnées et les données, les écritures de données doivent être opérées avant celles des métadonnées. Ceci peut être délicat à implémenter car cela requiert une coordination dans le noyau du système d'exploitation entre le pilote du système de fichier et le cache d'écriture. Ce système peut également être rendu compliqué par la présence de caches d'écriture embarqués sur le périphérique de stockage, qui vont eux-mêmes réorganiser les données dans le but de gagner en performances. Certains systèmes de fichiers vont alors sacrifier les performances pour favoriser l'intégrité des données, en forçant le vidage du tampon du périphérique après chaque écriture opérée par le journal.

Exemples d’implémentation

Ext3

Ce système de fichier est une extension de Ext2, auquel on a ajouté une fonction de journalisation. Il est donc possible de convertir une partition ext2 en une partition ext3 de manière simple, la seule modification à ajouter étant le journal. Il n'est utilisable que sur les systèmes Linux.

Les modes de journalisation

L'utilisateur a la possibilité de choisir parmi trois modes de journalisation :

mode Journal

Ce mode correspond à la journalisation physique. Les modifications apportés aux méta-données et au système de fichiers sont enregistrées dans le journal. Il s'agit du mode le plus sécurisé, il permet d'éviter au maximum que les modifications apportés ne soient perdues.

mode Writeback

Ce mode correspond à l'écriture à risque. Il est censé être le plus rapide des trois modes, dans le sens où il n'enregistre que les modifications des méta-données, et n'enregistre pas celles apportées au disque. Les écritures disque correspondantes peuvent être indifféremment exécutées avant ou après l'enregistrement dans le journal. il y a alors un risque, si un arrêt brutal du système intervient entre la journalisation et l'écriture effective sur le support, qu'il y ait une incohérence entre l'état du support de stockage et l'état du journal.

mode Ordered

Il s'agit du mode par défaut. Il correspond à la journalisation logique, et à l'instar du mode Writeback, seules les modifications apportées aux méta-données du système de fichiers sont enregistrées dans le journal. La différence est que l'écriture des modifications sur le disque est faite avant d'ajouter l'entrée dans le journal. Ainsi, on est sûr que les changements inscrits dans le journal ont bien été réalisés. En contrepartie, le fait que l'écriture sur le disque doive se faire avant de modifier le journal ne permet pas une souplesse d'ordonnancement des écritures disques, ce qui peut impliquer de légers ralentissements.

Performances

Ci-dessous un tableau comparant les temps d'exécution de certains algorithmes effectuant des opérations sur le disque. Plus les valeurs sont petites, plus le mode de journalisation est efficace.

Opération effectuée	Mode Writeback	Mode Journal	Mode Ordered
Creation	237.43	275.72	206.65
Copie	491.90	462.05	399.27
Lecture	240.17	242.61	234.17
Affichage des stats	22.36	22.36	22.36
Suppression	198.25	199.19	190.72
Écriture de large fichier	40.38	74.41	39.45
Lecture de large fichier	27.81	27.87	28.35

On peut déduire de ce tableau que sur presque tous les points, le mode journal est plus lent.

Commandes

Ce tableau résume les commandes utiles pour la gestion d'un système de fichier ext3.

Commandes	Description
mke2fs	Permet de créer un système de fichiers (option : -j pour faire un système de fichiers journalisé)
e2fsck	Vérifie ou répare un système de fichiers
debugfs	Dépanne le système de fichiers
ext2online	Agrandit un système de fichiers à chaud
ext2online	Redimensionne le système de fichier (non monté)
dumpe2fs	Affiche les informations du système de fichiers
dump	Sauvegarde le système de fichiers
restore	Restaure le système de fichiers
tune2fs	Modifie les paramètres du système de fichier

NTFS

Le système de fichiers NTFS utilise la journalisation à l'aide d'une structure appelée table de fichiers maître qui contient les informations détaillées des fichiers et répertoire présents sur le système de fichiers. Cette structure est décomposée en plusieurs enregistrements. Le premier contient les informations sur la MFT. Le second est une copie de la MFT. Le troisième enregistrement est le journal. C'est dans ce fichier que sont enregistrées toutes les actions effectuées sur la partition. On retrouve donc dans ce fichier des informations telles que le nom du fichier ou répertoire, la date de création et/ou de modification, les droits d'accès au fichier. La MFT représente une structure de stockage des données de la partition.

Performances

Avantages :

• La fragmentation n'influe pas sur les performances du système.
• La complexité de l'arborescence des fichiers et du nombre de fichiers n'affectent pas les performances.
• L'accès rapide au fragment des fichiers.

Inconvénients :

• La taille de la mémoire ne peut pas être inférieur à 64 mégaoctets.
• Les disques lents sans contrôle du bus ralentissent énormément les performances du système.
• Si le disque est occupé entre 80 % - 90 % de sa taille totale, les performances du systèmes sont ralenties.

Alternative

Copie Sur Écriture

La Copie Sur Écriture est à la base une technique d'optimisation des systèmes de fichiers. Lorsque plusieurs utilisateurs ou processus accèdent à une même ressource, au lieu de créer une copie pour chaque demandeur, aucune copie n'est faite et tout le monde utilise la même ressource. Si un utilisateur veut modifier la ressource, une copie privée est alors faite et les modifications sont enregistrés dessus. Ensuite, lorsque les modifications sont terminées, le pointeur vers la ressource redirige vers la copie. On peut imaginer utiliser ce principe pour éviter les incohérences des données. En effet, au lieu de modifier directement la ressource, et prendre le risque que l'écriture sur le disque ne se termine pas, lors d'un arrêt brutal du système, une copie est créée, les modifications s'effectue sur la copie et seulement après, la ressource pointe vers la copie et non l'original. Le seul risque ici est que la modification ne soit pas apportées, mais le système de fichier, par contre, ne contiendra pas d'incohérences.

Exemple : ZFS

ZFS est un système de fichiers transactionnel, ce qui lui permet d'assurer la cohérence de l'état des données. La journalisation est implémentée sur ZFS par le journal ZIL (ZFS Intent Log).Les appels au système de fichier sont associés à une entrée dans le ZIL, et renseignent les informations nécessaires à un éventuel rejeu. Chaque entrée du ZIL contient les données relatives à l'opération lorsqu'elles n'excèdent pas 64KB, ou contenir une référence vers celles-ci, stockées sur le disque. L'utilisation de journaux peut faire l'objet d'un déport sur un périphérique différent.

Évolution vers des systèmes journalisés

La sécurité des systèmes de fichier passe dans un premier temps par l'intégrité des données présentent sur ces derniers. En effet, le système de fichiers doit pouvoir garantir que les données présentes restent bien cohérentes même après un crash du système et doit permettre une récupération sur incident.

Systèmes de fichiers non journalisés

le système de fichiers ext2

Le système de fichier ext2 est le standard des systèmes de fichiers de Linux. Il a été écrit par Remy Card, Theodore T'so et Stephen Tweedie pour pallier les lacunes du système de fichiers ext1.

Fonctionnalités standard

Les fonctionnalités standard de ext2 permettent d'accéder à des partitions de 4 téraoctets (1 téraoctets = 1 024 gigaoctets), alors que la version ext1 ne permettait que des partitions de 2 gigaoctets (1 gigaoctets = 1 024 mégaoctets). La taille maximale des fichiers avec un système ext2 standard est de 2 gigaoctets. De plus, lors de la création du système de fichiers, le système réserve une certaine quantité d'espace pour le super-utilisateur (root), en général 5 %. Ceci permet au super-utilisateur de pouvoir se connecter sur le système et de faire des tâches administratives quand le système de fichiers est plein pour les utilisateurs. Ext2Fs gère aussi les noms de fichiers longs (255 caractères) et prend en compte tous les caractères excepté "NUL" et "/".

Récupération rapide sur incident

À la suite d'un plantage, il existe deux procédés pour permettre de récupérer les données :

1. Procédé des mises à jour prudentes qui, à un instant précis, rend le système de fichiers cohérent.
2. Procédé des programmes "éboueurs".

Le premier procédé consiste, à un instant précis, à ne pas laisser le système de fichiers incohérent. Ce procédé est très problématique car ne pas passer par une étape laissant le système dans une position incohérente est difficile. Par exemple, lorsqu'on crée un fichier, il faut ajouter ce fichier dans le répertoire et créer l'inode de ce répertoire. Ces opérations ne sont pas possibles simultanément et donc il se passe toujours un instant où l'inode est affecté au fichier mais pas au répertoire, ou l'inverse

Le deuxième procédé est celui employé par le système de fichier ext2. Il utilise l'utilitaire fsck pour vérifier l'intégrité et réparer les données. L'utilitaire est lancé au démarrage si le système détecte un problème sur le système de fichiers. À la suite de cela, l'utilitaire vérifie l'intégralité du disque. L'inconvénient majeur de cette méthode est le temps d’exécution qui est proportionnel à la taille du support. Pour procéder à la vérification, le déroulement de l'utilitaire fsck se décompose en 6 phases :

• Passe 1 : vérification des i-nœuds, des blocs et des tailles
• Passe 2 : vérification de la structure des répertoires
• Passe 3 : vérification de la connectivité des répertoires
• Passe 3A : optimisation des répertoires
• Passe 4 : vérification des compteurs de référence
• Passe 5 : vérification de l'information du sommaire de groupe

On remarque que le temps d’exécution dépend de la taille du disque. De ce fait, plus la taille du support est importante, plus l’exécution de fsck est longue.

Il était donc intéressant de pouvoir mélanger les deux procédés pour avoir une méthode de récupération beaucoup plus rapide.

Systèmes de fichiers journalisés

C'est ainsi qu'ont vu le jour les systèmes de fichiers journalisés. Ces systèmes ont été conçus pour améliorer la reprise sur incident en s'inspirant des gestionnaires de base de données. Les SGBD utilisent des systèmes transactionnels c'est-à-dire que l'écriture des données est différée, et chaque mise à jour est représentée comme une opération atomique : la mise à jour s'effectue entièrement ou ne s'effectue pas. Il est donc possible de réduire les opérations d'écriture/lecture sous la forme de transaction qui ne sera effective que lorsque le système de fichiers aura validé les modifications. Ces transactions sont écrites dans un journal. Certains systèmes de fichiers journalisés n'inscrivent que les méta-données, alors que d'autres y inscrivent toutes les opérations (lectures/écritures).

Tableau des différents systèmes de fichiers journalisés existants

Système de fichiers	Utilisé par	Remarque(s)
APFS	Mac OS
BFS	BeOS et Haiku	OFS avec un journal et un adressage 64 bits
ext3	principalement Linux	ext2 avec la gestion de la journalisation
ext4	principalement Linux	Il est le successeur de ext3 mais considéré comme solution intermédiaire par ses concepteurs
HFS+	Mac OS	En option
JFS	principalement AIX, mais aussi Linux
NTFS	Windows
ReiserFS	principalement Linux	Non recommandé pour les ordinateurs portables, car le disque dur tourne en permanence, ce qui consomme beaucoup d'énergie.
UFS	principalement FreeBSD
VxFS	principalement HP-UX
XFS	plusieurs systèmes UNIX
ZFS	principalement OpenSolaris

Historique

• Le système JFS (Journaling File System), initialement développé par IBM au milieu des années 1990, fut le premier à utiliser des fonctions de journalisation.
• NTFS apparaît en 1993, dans les premières versions de Windows NT, ajoutant outre la journalisation, la possibilité d'y installer un système multi-utilisateurs, grâce à l'ajout de méta-données telles qu'un propriétaire du fichier et des droits d'accès.
• Apple publie HFS+ en 1998, une amélioration de HFS, ajoutant principalement le système de journalisation et d'autres modifications.
• Ext3 est le fruit d'une amélioration de ext2 faite par Stephen Tweedie courant de l'année 1999. Ce système de fichier est alors inclus la branche 2.4.15 de Linux en novembre 2001.
• XFS, écrit par SGI, était destiné pour le système d'exploitation propriétaire IRIX. C'est en mai 2000 que XFS est publié sous Licence GPL.
• ReiserFS, développé par Namesys, fut introduit dans la branche 2.4.1 de Linux en 2001.

Liens externes

• (en) « Journaling Filesystem Definition », The Linux Information Project,‎ 13 avril 2007 (lire en ligne)

• (en) Jonathan Corbet, « Barriers and journaling filesystems », Linux info from the source,‎ 21 mai 2008 (lire en ligne)

• (en) Steve Best, « JFS Log », 4th Annual Linux Showcase & Conference, Atlanta,‎ octobre 2000 (lire en ligne)
• (en) Chris Mason, « Journaling with ReiserFS », Linux Journal,‎ 1^er février 2001 (lire en ligne)
• (en) M. Hans T. Reiser, « Enhancing ReiserFS Security In Linux », DARPA Information Survivability Conference and Exposition, 2003. Proceedings, IEEE,‎ 22 avril 2003 (ISBN 0-7695-1897-4, DOI 10.1109/DISCEX.2003.1194963)
• (en) Michael K. Johnson, « Whitepaper: Red Hat's New Journaling File System: ext3 », redhat ressource library,‎ 1^er novembre 2001 (lire en ligne)
• (en) Dr. Stephen Tweedie, « EXT3, Journaling Filesystem », Ottawa Linux Symposium,‎ 20 juillet 2000 (lire en ligne)
• « Description d'Oracle Solaris ZFS », Oracle Solaris 11 Information Library (Français),‎ février 2012 (lire en ligne)
• (en) Nadgir Neelakanth, « The ZFS Intent Log », Neelakanth Nadgir's blog (Oracle),‎ 16 novembre 2005 (lire en ligne)
• « Configuration de périphériques de journal ZFS distincts », Oracle Solaris 11 Information Library (Français),‎ août 2011 (lire en ligne)
• (en) SIG, « XFS: A high-performance journaling filesystem », sur Site web du projet XFS
• (en) M. Qianqian Ge et Yiwei Zhu, « The Structure and Implementation of Journaling File System on Embedded System », dans 2005 International Conference on Dependable Systems and Networks, 28 June-1 July 2005, Yokohama, Japan : proceedings, IEEE, 28 décembre 2008 (ISBN 978-0-7695-3811-2, DOI 10.1109/FBIE.2008.74), p. 140 - 143
• (en) « Disk Organization », sur FreeBSD Handbook
• (en) Steve Best, « Journaling Filesystem Definition », Linux Magazine,‎ 15 octobre 2002 (lire en ligne)
• (en) Rémy Card, Theodore Ts'o et Stephen Tweedie, « Design and Implementation of the Second Extended Filesystem », dans Proceedings to the first Dutch international symposium on Linux, Amsterdam, December 8th and 9th, 1994 (ISBN 90-367-0385-9, lire en ligne)
• (en) M. Vijayan Prabhakaran, « Model-based failure analysis of journaling file systems », Dependable Systems and Networks, 2005. DSN 2005. Proceedings. International Conference on, IEEE,‎ 25 juillet 2005, p. 802 - 811 (ISBN 0-7695-2282-3, DOI 10.1109/FBIE.2008.74)
• (en) M. Tim Jones, « Anatomy of Linux journaling file systems », sur IBM.com
• « Manuel de la commande fsck », sur linuxcertif.com
• (en) Vijayan Prabhakaran, Andrea C. Arpaci-Dusseau et Remzi H. Arpaci-Dusseau, « Analysis and Evolution of Journaling File Systems », The 2005 USENIX Annual Technical Conference (USENIX '05),‎ avril 2005 (lire en ligne)
• (en) Microsoft, « Master File Table », sur Microsoft Developer Network, août 2012
• (en) Bill Von Hagen, « Exploring the ext3 Filesystem », Linux planet,‎ avril 2002 (lire en ligne)
• (en) « Some amazing filesystem benchmarks », Site web Linuxhelp.150m.com,‎ juin 2005 (lire en ligne)
• (en) Francisco Javier Thayer Fábrega, Francisco Javier et Joshua D. Guttman, Copy On Write, 1995 (CiteSeer^x 10.1.1.33.3144)