En cas de plantage, le système doit être capable de conserver le maximum de données. La journalisation des systèmes de fichiers (File System ou FS) fait partie des moyens mis en place pour satisfaire à cette exigence. Le système de fichiers est un des éléments clés d’un système d’exploitation. Il donne à l’ensemble du système le moyen de retrouver les données inscrites sur les disques et organisées en fichiers, dossiers et arborescences.Il faut rappeler ici que tout disque dur est divisé en blocs, les unités de base du stockage. Leur taille varie de 512 octets à 4 Ko selon les systèmes. Ces blocs sont référencés par un système de coordonnées exprimé sous la forme d’une série de chiffres (cylindre, secteur du cylindre, bloc du secteur). Ces informations sont une partie des métadonnées qui figurent dans la table d’allocation, ainsi nommée parce qu’elle s’apparente à la table d’une base de données.
Préserver les métadonnées
À chaque fois qu’un fichier est inscrit sur le disque, le ou les blocs qu’il occupe sont référencés dans la table d’allocation. Celle-ci, qui renferme toutes les métadonnées, est elle-même écrite dans un secteur particulier du disque dur. Lorsque le système a besoin de retrouver un fichier, il interroge le FS qui consulte la table d’allocation, cherche les métadonnées relatives au fichier, lit ses coordonnées sur le disque et remonte le fichier pour le rendre disponible. Mais la gestion de cette table d’allocation est problématique.En effet, historiquement, il existe deux méthodes. La première est asynchrone : lors d’une écriture de données, le FS crée les métadonnées dans une table d’allocation temporaire en mémoire vive, écrit le fichier sur le disque dur, puis écrit les nouvelles métadonnées (jusqu’alors encore en mémoire vive) dans la table d’allocation du disque dur lorsqu’il a les ressources nécessaires. En effet, la modification fréquente de la table d’allocation, coûteuse en temps de calcul, bride les performances du système.
Traitement synchrone ou asynchrone
Or, si un crash se produisait une fois les données inscrites sur le disque alors même que les métadonnées ne le sont pas encore, la table d’allocation ne serait pas modifiée. Lors du redémarrage du système, la mémoire vive étant purgée, surgit alors le risque de ne pas retrouver le fichier écrit car non repéré dans la table, et de se retrouver avec des incohérences entre le contenu du disque et la table qui rendent impossible le bon fonctionnement du système.L’autre méthode est synchrone, toutes les modifications de données et métadonnées sont écrites sur le disque dur en temps réel. Cette méthode ralentit assez sérieusement le système car elle requiert un nombre important d’opérations.
Une opération atomique de mise à jour
Répondant aux problèmes sur lesquels butent encore ces deux métho-des, la journalisation recourt à un principe transactionnel inspiré des bases de données pour garantir l’intégrité de la table d’allocation et la cohérence des métadonnées à quelque moment que ce soit. Lorsque le FS veut actualiser les métadonnées, il construit une seconde table d’allocation située ailleurs sur le disque (ce qu’on nomme journal). La table d’origine reste active durant cette construction. Une fois celle-ci totalement terminée, le FS commute alors sur la nouvelle table d’allocation par une opération dite atomique car insécable. Une fois lancées, rien ne peut arrêter les opérations atomiques : que le système tombe, que le processeur prenne feu ou que le courant soit coupé, l’opération entamée est forcément menée jusqu’à son terme. D’où le nom de journalisation : lundi sort un premier numéro du journal qui est complet, et mardi sort un autre numéro qui remplace le premier. À aucun moment le numéro de lundi n’est transformé en numéro du mardi.
Toujours préserver une table d’allocation cohérente
À un instant donné, il existe une table d’allocation complète A1, diverses opérations ont lieu ensuite sur le disque et le FS construit une seconde table d’allocation A2 pour remplacer la première, qui reste active, puis le système remplace A1 par A2 après que la construction de cette dernière soit complètement achevée. Dans tous les cas, le FS dispose d’une table d’allocation complète. Si jamais le système devait planter avant que la construction de la table A2 ne soit terminée, il pourrait toujours se rabattre sur la table A1 qui, elle, est restée cohérente. La perte de fichiers est minimale, et l’examen d’intégrité ne porte pas sur l’ensemble du disque mais seulement sur les éléments différents entre A1 et A2.Pour des raisons pratiques et pour éviter la fragmentation de la table d’allocation, la nouvelle table d’allocation (journal) est en fait recopiée à l’emplacement de l’ancienne, suite à quoi le FS commute de nouveau et libère l’emplacement du journal.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
