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[modifier | modifier le code]
La journalisation du système de fichier assure la cohérence des données en utilisant un journal[1]. 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[modifier | modifier le code]
Journaux physiques[modifier | modifier le code]
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[2].
Journaux logiques[modifier | modifier le code]
Le journal logique ne stocke que les métadonnées, sacrifiant la tolérance aux pannes pour de meilleures performances[3]. 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[modifier | modifier le code]
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[4].
Exemples d’implémentation[modifier | modifier le code]
Ext3[modifier | modifier le code]
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[modifier | modifier le code]
L'utilisateur a la possibilité de choisir parmi trois modes de journalisation[5] :
mode Journal[modifier | modifier le code]
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[modifier | modifier le code]
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[modifier | modifier le code]
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[modifier | modifier le code]
Ci-dessous un tableau comparant les temps d'exécution de certains algorithmes effectuant des opérations sur le disque[6]. 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[modifier | modifier le code]
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[modifier | modifier le code]
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[7]. 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[7]. 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[modifier | modifier le code]
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[modifier | modifier le code]
Copie Sur Écriture[modifier | modifier le code]
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[8]. 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[modifier | modifier le code]
ZFS est un système de fichiers transactionnel, ce qui lui permet d'assurer la cohérence de l'état des données[9]. La journalisation est implémentée sur ZFS par le journal ZIL (ZFS Intent Log)[10].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[11].
Évolution vers des systèmes journalisés[modifier | modifier le code]
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[modifier | modifier le code]
le système de fichiers ext2[modifier | modifier le code]
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[modifier | modifier le code]
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[12]. Ext2Fs gère aussi les noms de fichiers longs (255 caractères) et prend en compte tous les caractères excepté "NUL" et "/"[13].
Récupération rapide sur incident[modifier | modifier le code]
À la suite d'un plantage, il existe deux procédés pour permettre de récupérer les données :
- Procédé des mises à jour prudentes qui, à un instant précis, rend le système de fichiers cohérent.
- 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[modifier | modifier le code]
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).
| 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[modifier | modifier le code]
- 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 [14].
- XFS, écrit par SGI, était destiné pour le système d'exploitation propriétaire IRIX. C'est en que XFS est publié sous Licence GPL.
- ReiserFS, développé par Namesys, fut introduit dans la branche 2.4.1 de Linux en 2001.
Références[modifier | modifier le code]
- Best 2000, p. 1
- EXT3, Journaling Filesystem
- Analysis and Evolution of Journaling File Systems
- Barriers and journaling filesystems
- Ext3 : Mode de journalisation 2002
- Benchmarks de Système de fichiers 2005
- msdn Master File Table 2012
- Francisco Javier Thayer Fábrega, Francisco Javier et Joshua D. Guttman 1995, Copy On Write, p. 2-10
- Description d'Oracle Solaris ZFS, p. 1
- The ZFS Intent Log, p. 1
- Configuration de périphériques de journal ZFS distincts, p. 1
- Le mode graphique nécessite généralement l’écriture d’informations dans l’espace personnel
- Standard Ext2fs features
- (en) « Re: fsync on large files »(Archive.org • Wikiwix • Archive.is • Google • Que faire ?)
Liens externes[modifier | modifier le code]
- (en) « Journaling Filesystem Definition », The Linux Information Project, (lire en ligne)
- (en) Jonathan Corbet, « Barriers and journaling filesystems », Linux info from the source, (lire en ligne)
- (en) Steve Best, « JFS Log », 4th Annual Linux Showcase & Conference, Atlanta, (lire en ligne)
- (en) Chris Mason, « Journaling with ReiserFS », Linux Journal, (lire en ligne)
- (en) M. Hans T. Reiser, « Enhancing ReiserFS Security In Linux », DARPA Information Survivability Conference and Exposition, 2003. Proceedings, IEEE, (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, (lire en ligne)
- (en) Dr. Stephen Tweedie, « EXT3, Journaling Filesystem », Ottawa Linux Symposium, (lire en ligne)
- « Description d'Oracle Solaris ZFS », Oracle Solaris 11 Information Library (Français), (lire en ligne)
- (en) Nadgir Neelakanth, « The ZFS Intent Log », Neelakanth Nadgir's blog (Oracle), (lire en ligne)
- « Configuration de périphériques de journal ZFS distincts », Oracle Solaris 11 Information Library (Français), (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, (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, (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, , 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), (lire en ligne)
- (en) Microsoft, « Master File Table », sur Microsoft Developer Network,
- (en) Bill Von Hagen, « Exploring the ext3 Filesystem », Linux planet, (lire en ligne)
- (en) « Some amazing filesystem benchmarks », Site web Linuxhelp.150m.com, (lire en ligne)
- (en) Francisco Javier Thayer Fábrega, Francisco Javier et Joshua D. Guttman, Copy On Write, (CiteSeerx 10.1.1.33.3144)
