Maison  >  Article  >  Tutoriel système  >  Une plongée approfondie dans le système de fichiers de journalisation ext3 dans CentOS

Une plongée approfondie dans le système de fichiers de journalisation ext3 dans CentOS

王林
王林avant
2024-01-13 12:39:171139parcourir

Contour

1. Système de fichiers de journal

2. Avantages d'ext3

3, trois modes de journalisation d'ext3

4. Sélectionnez le mode journal

1. Système de fichiers de journal

Habituellement, lorsque le contenu du fichier est écrit pendant que le système est en cours d'exécution, les métadonnées du fichier (telles que les autorisations, le propriétaire, l'heure de création et d'accès) ne sont pas écrites s'il y a un décalage horaire entre l'écriture du contenu du fichier et avant l'écriture des métadonnées du fichier. est Si le système s'arrête anormalement, le système de fichiers en cours d'écriture sera déchargé anormalement et le système de fichiers sera dans un état incohérent. Lors du redémarrage, Linux exécutera le programme fsck, analysant l'intégralité du système de fichiers pour s'assurer que tous les blocs de fichiers sont correctement alloués ou utilisés, trouvant les entrées de répertoire endommagées et essayant de les réparer. Cependant, fsck ne garantit pas que les dommages seront réparés. Lorsque cela se produit, des métadonnées incohérentes dans le fichier rempliront l'espace du fichier perdu et les entrées de fichier dans l'entrée de répertoire peuvent être perdues, entraînant la perte du fichier.

Afin de minimiser l'incohérence du système de fichiers et de raccourcir le temps de démarrage du système d'exploitation, le système de fichiers doit suivre les enregistrements qui provoquent des modifications du système. Ces enregistrements sont stockés dans un endroit distinct du système de fichiers, généralement appelé. un journal". Une fois ces enregistrements de journaux écrits en toute sécurité, le système de fichiers journaux peut les utiliser pour nettoyer les enregistrements qui ont provoqué la modification du système et les organiser dans un ensemble qui a provoqué la modification du système de fichiers, en les plaçant dans la transaction de base de données et en les conservant dans le répertoire. état. Le fonctionnement normal des données valides n’entre pas en conflit avec les performances de l’ensemble du système. En cas de panne du système ou de nécessité de redémarrage, les données sont restaurées selon les informations enregistrées dans le fichier journal. Comme il y a des points de contrôle réguliers dans les fichiers journaux, ils sont généralement très bien rangés. La conception du système de fichiers prend principalement en compte les problèmes d'efficacité et de performances.

Linux peut prendre en charge de nombreux systèmes de fichiers journaux, notamment FAT, VFAT, HPFS (OS/2), NTFS (Windows NT), UFS, XFS, JFS, ReiserFS, ext2, ext3, etc.

2. Avantages d'ext3

Pourquoi devez-vous migrer d'ext2 vers ext3 ? Voici quatre raisons principales : disponibilité, intégrité des données, rapidité, facilité de migration.

Disponibilité

Après un crash anormal (panne de courant, crash du système), le système de fichiers ext2 ne peut être monté et utilisé qu'après vérification de cohérence via e2fsck. Le temps d'exécution de e2fsck dépend principalement de la taille du système de fichiers ext2. La vérification de systèmes de fichiers légèrement plus volumineux (des dizaines de gigaoctets) prend beaucoup de temps. S'il existe de nombreux fichiers sur le système de fichiers, la vérification prendra plus de temps. La vérification d'un système de fichiers de plusieurs centaines de gigaoctets peut prendre une heure ou plus. Cela limite considérablement la convivialité. En revanche, sauf en cas de panne matérielle, ext3 ne nécessite pas de vérification du système de fichiers même s'il est arrêté anormalement. En effet, les données sont écrites sur le disque de manière cohérente dans tout le système de fichiers. Après un arrêt anormal, le temps de restauration d'un système de fichiers ext3 ne dépend pas de la taille du système de fichiers ni du nombre de fichiers, mais de la taille du « log » nécessaire pour maintenir la cohérence. Avec les paramètres de journalisation par défaut, le temps de récupération n'est que d'une seconde (en fonction de la vitesse du matériel).

Intégrité des données

Grâce au système de fichiers ext3, les performances d'intégrité des données sont garanties de manière fiable en cas d'arrêt anormal. Vous pouvez choisir le type et le niveau de protection des données. Vous pouvez choisir de conserver la cohérence du système de fichiers, mais permettre que les données du système de fichiers soient endommagées lors d'un arrêt anormal ; cela peut améliorer la vitesse dans certaines situations (mais pas dans toutes les situations). Vous pouvez également choisir de maintenir la fiabilité des données en cohérence avec le système de fichiers ; cela signifie qu'après un crash, vous ne verrez aucune donnée inutile dans les fichiers nouvellement écrits. Cette option sécurisée, qui maintient l'intégrité des données en cohérence avec le système de fichiers, est le paramètre par défaut.

Vitesse

Bien que ext3 écrit des données plus de fois que ext2, ext3 est souvent plus rapide que ext2 (flux de données élevé). En effet, la fonction de journalisation d'ext3 optimise la rotation des têtes de disque dur. Vous pouvez choisir parmi 1 des 3 modes de journalisation pour optimiser la vitesse, en sacrifiant de manière sélective une certaine intégrité des données. Le premier mode, data=writeback, garantit une intégrité limitée des données et permet aux anciennes données d'exister dans le fichier après un crash. Ce mode peut améliorer la vitesse dans certaines situations. (Dans la plupart des systèmes de fichiers de journalisation, ce mode est le paramètre par défaut. Ce mode fournit une intégrité limitée des données pour le système de fichiers ext2 et vise davantage à éviter une longue vérification du système de fichiers au démarrage du système.) Deuxièmement, ce mode, data = orderd (le mode par défaut ), maintient la fiabilité des données en cohérence avec le système de fichiers ; cela signifie qu'après un crash, vous ne verrez aucune donnée indésirable dans les fichiers nouvellement écrits. Le troisième mode, data=journal, nécessite un journal plus grand pour garantir une vitesse modérée dans la plupart des cas. La récupération après un crash prend également plus de temps. Mais ce sera plus rapide dans certaines opérations de base de données. Dans des circonstances normales, il est recommandé d'utiliser le mode par défaut. Si vous devez changer de mode, veuillez ajouter l'option data=mode au système de fichiers correspondant dans le fichier /etc/fstab. Pour plus de détails, veuillez vous référer à la page de manuel du manuel en ligne de la commande mount (exécuter man mount).

Facile à migrer

Vous pouvez facilement migrer d'ext2 vers ext3 sans reformater le disque dur et profiter des avantages d'un système de fichiers de journalisation fiable. Oui, vous pouvez bénéficier des avantages d'ext3 sans effectuer l'opération de "sauvegarde-reformatage-restauration" longue, ennuyeuse et potentiellement sujette aux erreurs. Il existe deux méthodes de migration :

Si vous mettez à niveau votre système, le programme d'installation de Red Hat Linux vous aidera à la migration. Tout ce que vous avez à faire est de cliquer sur le bouton Sélectionner pour chaque système de fichiers.

Utilisez le programme tune2fs pour ajouter une fonctionnalité de journalisation à un système de fichiers ext2 existant. Si le système de fichiers a été monté pendant le processus de conversion, le fichier « .journal » apparaîtra dans le répertoire racine ; si le système de fichiers n'a pas été monté, le fichier n'apparaîtra pas dans le système de fichiers. Pour convertir le système de fichiers, exécutez simplement tune2fs –j /dev/hda1 (ou tout autre nom de périphérique sur lequel se trouve le système de fichiers que vous souhaitez convertir) et remplacez ext2 dans le fichier /etc/fstab par ext3. Si vous souhaitez convertir votre propre système de fichiers racine, vous devez utiliser initrd pour démarrer. Exécutez le programme conformément à la description manuelle de mkinitrd et confirmez que initrd est chargé dans votre configuration LILO ou GRUB (s'il échoue, le système peut toujours démarrer, mais le système de fichiers racine sera chargé en tant qu'ext2 au lieu d'ext3. Vous pouvez utiliser la commande cat / proc/mounts pour le confirmer.) Pour plus de détails, veuillez vous référer à la page de manuel du manuel en ligne de la commande tune2fs (exécuter man tune2fs).

3, trois modes de journalisation d'ext3

Ext3 fournit plusieurs modes de journalisation, c'est-à-dire qu'il s'agisse de modifier les métadonnées du système de fichiers ou de modifier les données du système de fichiers (y compris les modifications apportées au fichier lui-même), le système de fichiers ext3 peut le prendre en charge. Ce qui suit est activé lorsque le /. Le fichier etc/fstab est démarré. Trois modes de journalisation différents :

data=mode journal

Les enregistrements du journal incluent toutes les données et métadonnées qui ont modifié le système de fichiers. C'est le plus lent des trois modes de journalisation ext3, mais il minimise les risques d'erreurs. L'utilisation du mode "data=journal" nécessite que ext3 écrive chaque modification dans le système de fichiers deux fois et dans le journal une fois, ce qui réduira les performances globales du système de fichiers. Toutes les nouvelles données sont d'abord écrites dans le journal, puis localisées. Après un accident, les journaux peuvent être relus pour ramener les données et métadonnées à un état cohérent. Étant donné que les métadonnées et les mises à jour des données dans ext3 sont enregistrées, ces journaux prendront effet au redémarrage d'un système.

data=mode journal ordonné (par défaut)

Seules les métadonnées du système de fichiers modifié sont enregistrées et les données du fichier de débordement doivent être ajoutées au disque. Il s'agit du mode de journalisation ext3 par défaut. Ce mode réduit la redondance entre l'écriture dans le système de fichiers et l'écriture dans le journal, il est donc plus rapide. Bien que les modifications des données du fichier ne soient pas enregistrées dans le journal, elles doivent être effectuées et sont contrôlées par le programme démon ext3 exécuté avant. modifications des métadonnées du système de fichiers associées, c'est-à-dire que les données du système de fichiers doivent être modifiées avant d'enregistrer les métadonnées. Cela réduira légèrement les performances (vitesse) du système, mais cela peut garantir que les données du système de fichiers sont cohérentes avec celles du système de fichiers. système de fichiers correspondant.

data=mode journal d'écriture différée

Enregistre uniquement les métadonnées des modifications apportées au système de fichiers, mais selon le système de fichiers standard, le programme d'écriture doit toujours enregistrer les modifications des données de fichier sur le disque pour maintenir la cohérence du système de fichiers. Il s'agit du mode de journalisation ext3 le plus rapide. Parce qu'il enregistre uniquement les modifications des métadonnées sans attendre les mises à jour liées aux données du fichier telles que la taille du fichier, les informations sur le répertoire, etc., la mise à jour des données du fichier et l'enregistrement des modifications des métadonnées peuvent être asynchrones, c'est-à-dire qu'ext3 prend en charge les journaux asynchrones. Le problème est que lorsque le système est arrêté, les données mises à jour sont incohérentes car elles ne peuvent pas être écrites sur le disque. Ce problème ne peut pas encore être résolu.

Il existe des différences entre les différents modes de journalisation, mais la méthode de réglage est la même et pratique. Le mode journal peut être spécifié à l'aide du système de fichiers ext3, ce qui est effectué au démarrage par /etc/fstab. Par exemple, si vous sélectionnez le mode de journalisation data=writeback, vous pouvez définir les paramètres suivants :

/dev/hda5 /opt ext3 data=writeback 1 0

Dans des circonstances normales, le mode de journalisation data=ordered est le mode par défaut du système de fichiers ext3.

Pour spécifier la méthode de journalisation, vous pouvez utiliser la méthode suivante :

1 Ajoutez la chaîne appropriée au champ d'options de /etc/fstab, par exemple data=journal

# /dev/sda3 /var ext3 valeurs par défaut, data=writeback 1 2

2 Spécifiez directement l'option de ligne de commande -o data=journal lors de l'appel de mount.

# mount -o data=journal /dev/sdb1 /mnt

Si nous voulons vérifier le mode de journalisation d'un certain système de fichiers, comment pouvons-nous l'interroger via la commande dmesg :

# dmesg | grep -B 1 "système de fichiers monté"

kjournald démarrant. Intervalle de validation 5 secondes

EXT3-fs : système de fichiers monté avec mode données ordonnées.

--

EXT3 FS sur sda1, journal interne

EXT3-fs : système de fichiers monté avec mode données ordonnées.

--

EXT3 FS sur sdb1, journal interne

EXT3-fs : système de fichiers monté avec mode données de journal.

--

EXT3 FS sur sdb1, journal interne

EXT3-fs : système de fichiers monté avec mode de données en écriture différée.

4. Sélectionnez le mode journal

Vitesse

Dans certains cas typiques, l'utilisation de l'option data=writeback peut améliorer considérablement la vitesse, mais en même temps cela réduira la protection de la cohérence des données. Dans ces cas, la protection de la cohérence des données est essentiellement la même que pour le système de fichiers ext2, sauf que pendant le fonctionnement normal, le système maintient en permanence l'intégrité du système de fichiers (c'est le mode de journalisation utilisé par d'autres systèmes de fichiers de journalisation). Cela inclut des opérations d'écriture partagées fréquentes, mais également la création et la suppression fréquentes d'un grand nombre de petits fichiers, comme l'envoi d'un grand nombre de petits messages électroniques. Si vous passez d'ext2 à ext3 et constatez que les performances de l'application diminuent considérablement, l'option data=writeback peut vous aider à améliorer les performances. Même si vous ne bénéficiez pas de mesures coûteuses de protection de la cohérence des données, vous pouvez toujours profiter des avantages d'ext3 (le système de fichiers est toujours cohérent). Red Hat continue de travailler pour améliorer certains aspects des performances d'ext3, de sorte que certains aspects des performances d'ext3 pourront être améliorés à l'avenir. Cela signifie également que même si vous choisissez data=writeback maintenant, vous devez retester les versions futures avec la valeur par défaut data=journal pour déterminer si les modifications apportées à la nouvelle version sont pertinentes pour votre travail.

Intégrité des données

Dans la plupart des cas, les utilisateurs écrivent les données à la fin du fichier. Ce n'est que dans certains cas (comme dans les bases de données) que les utilisateurs écrivent des données au milieu d'un fichier existant. Même l'écrasement d'un fichier existant est réalisé en tronquant d'abord le fichier, puis en écrivant les données à partir de la fin du fichier. En mode data=ordered, si le système plante pendant l'écriture d'un fichier, le bloc de données peut être partiellement écrasé, mais le processus d'écriture n'est pas terminé, le système dispose donc de blocs de données incomplets qui n'appartiennent à aucun fichier. En mode data=ordered, la seule situation dans laquelle des blocs de données non ordonnés restent après un crash est si un programme réécrit un fichier pendant le crash. Dans ce cas, il n'y a aucune garantie absolue de l'ordre d'écriture à moins que le programme n'utilise fsync() et O_SYNC pour forcer les écritures à se produire dans un ordre spécifique.

Le système de fichiers ext3 implique également comment vider les données du cache sur le disque dur. Il implémente un vidage régulier via le processus kupdate. Par défaut, il vérifie toutes les 5 secondes et vide les données sales qui dépassent 30 secondes sur le disque dur.

Dans la version 3.0, l'objectif peut être atteint en modifiant /proc/sys/vm/bdflush. Dans la version 4.0, l'objectif peut être atteint en modifiant /proc/sys/vm/dirty_writeback_centisecs et /proc/sys/vm/dirty_expire_centisecs.

Étant donné que la valeur par défaut est le mode ordonné, dans ce mode, si un IO écrit d'abord le fichier de données, puis écrit le fichier journal. Si le système plante après l'écriture du fichier de données et avant l'écriture du fichier journal, cette partie des données sera perdue. Ceci n'est absolument pas autorisé dans la base de données, qu'elle soit Oracle ou MySQL. Donc Pour les écritures dans la base de données, chaque opération d'écriture sera d'abord écrite dans le cache de page, puis le kernelthread sera informé de vider les tampons sur le disque dur, puis les métadonnées seront écrites dans le journal, et enfin l'opération d'écriture réussie sera restitué. De cette façon, les opérations d'écriture dans la base de données ne sont évidemment pas aussi rapides que l'écriture sur des appareils nus.

Ainsi, lorsque vous utilisez Ext3 pour exécuter la base de données, réglez le mode journal sur le mode journal, les performances devraient être améliorées (cela n'a pas été testé, l'analyse théorique devrait être comme ceci). Car en mode journal, pour une opération d'écriture dans la base de données, les modifications des données et du système de fichiers sont d'abord écrites directement dans le journal (l'écriture directe contourne le cache, ce qui offre de meilleures performances), puis les données sont écrites dans le cache, puis le processus kupdate actualise les données sur le disque dur. En revanche, pour DB, ses performances devraient être plus rapides que la précédente.

De plus, voici le paramètre sync_binlog dans MySQL. Si ce paramètre est défini sur 1, cela signifie que chaque fois que le fichier binlog est écrit, il sera vidé sur le disque dur en même temps, tout comme l'écriture des IO par Oracle. Si ce paramètre est désactivé, il sera géré par le système d'exploitation, c'est-à-dire qu'il sera vérifié toutes les 5 secondes. Si d'anciennes données d'il y a 30 secondes sont trouvées, elles seront vidées sur le disque dur. Le paramètre innodb_flush_log_at_trx_commit implique également le problème du vidage du disque dur.

Ext3, en tant que version améliorée d'ext2, est presque identique au superbloc, à l'inode, au descripteur de groupe et aux autres structures de données utilisés par ext2, donc ext3 est compatible avec ext2. Sans sauvegarder les données du système de fichiers ext2, vous pouvez utiliser :

1

# tune2fs –j/dev/sd1

Convertissez le système de fichiers ext2 directement en système de fichiers ext3 sans démonter la partition.

Supposons que lorsque nous modifions un fichier, il y ait une panne de courant soudaine, ou que le système soit verrouillé et obligé de redémarrer, quelles seront les conséquences ? Au pire, une partie du contenu du fichier est perdue, au pire, tout le contenu du fichier est gâché et, pire encore, le système de fichiers plante directement. Quelle chose terrible ce serait. Lorsque Linux s'arrête normalement, nous verrons un message d'impression indiquant la désinstallation du système de fichiers. Un arrêt anormal entraînera des incohérences dans le système de fichiers. Cette incohérence sera découverte lorsque le système de fichiers sera monté pendant la phase de redémarrage du système. essayez de le réparer. Malheureusement, à mesure que la capacité des périphériques de stockage augmente, le temps requis pour de telles réparations devient de plus en plus prohibitif.

La plus grande fonctionnalité d'Ext3 est qu'il ajoute une fonction de journalisation basée sur ext2, de sorte que le système de fichiers ext3 est souvent appelé système de fichiers journaux, mais le système de fichiers journaux n'est pas seulement ext3, mais aussi JFS, reiserFS et XFS. Ainsi que NTFS, etc. que l’on voit souvent sous Windows.

La fonctionnalité de journalisation d'Ext3 repose principalement sur un périphérique intermédiaire appelé "Journaling Block Device Layer" en dessous, appelé JBD (Journaling Block Device layer, JBD en abrégé). JBD ne fait pas partie de la spécification du système de fichiers. Cela n'a rien à voir avec la spécification du système de fichiers ext3. JBD est la base de l'implémentation de la fonction de traitement des transactions du système de fichiers. En bref, JBD est conçu pour mettre en œuvre l'objectif particulier de se connecter sur n'importe quel périphérique de bloc (plus cela devient abstrait, qu'est-ce qu'une transaction ? ⊙﹏⊙…)

Concernant les transactions, les étudiants qui ont de l'expérience dans le développement de bases de données ou dans l'exploitation et la maintenance de données la connaîtront certainement. Nous ne nous en tiendrons pas ici à des concepts ou à des définitions académiques, pour autant que chacun sache que la fonction principale des transactions est d’assurer l’atomicité des opérations. Comment comprendre cette phrase ? Par exemple, dans le système financier, X yuans doivent être transférés du compte A au compte B. Cette entreprise doit s'assurer que X yuans est transféré avec succès du compte A, puis que X yuans sont ajoutés avec succès au compte B. Ce n'est que si ces deux opérations réussissent en même temps que le transfert peut réussir. Si l'une ou l'autre des opérations échoue, l'entreprise doit cesser. Si le transfert de X yuans du compte A réussit et qu'une erreur se produit lors de l'écriture sur le compte B, alors les X yuans transférés du compte A doivent être restitués au compte A. Une situation plus extrême est que les données du compte A s'effondrent pour diverses raisons. Le mécanisme de transaction de la base de données doit alors garantir que les X yuans du compte A ne seront pas perdus. Il s’agit de l’atomicité des opérations commerciales des bases de données. Dans le système de fichiers journaux, l'atomicité des opérations sur les données des fichiers est garantie par JBD qui implémente sa fonction de journalisation en « s'accrochant » à l'API de JBD. Bien que la couche JBD elle-même ne contienne pas beaucoup de code, il s'agit d'une partie logicielle très complexe. Nous n'en parlerons pas ici, et nous jouerons avec lorsque nous en aurons l'occasion. Le système de fichiers journaux doit bien sûr enregistrer les journaux, et les journaux nécessitent également de l'espace de stockage. Par conséquent, le système de fichiers journaux ouvre une zone spéciale sur le support de stockage spécifiquement pour stocker les informations du journal :

Une plongée approfondie dans le système de fichiers de journalisation ext3 dans CentOSNous utilisons une image pour décrire brièvement la disposition sous-jacente d'ext3 :

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Déclaration:
Cet article est reproduit dans:. en cas de violation, veuillez contacter admin@php.cn Supprimer