À tous, excellent week-end ! Nous vous invitons à une démonstration gratuite , animée par Andreï Boulanov — spécialiste des systèmes UNIX chez Mail.Ru Group. Nous publions également un article de Jonathan Corbet — rédacteur en chef chez LWN.net.
Les systèmes de fichiers journalisés promettent de libérer les administrateurs système des problèmes de corruption de disque lors de pannes système. Même sans lancer un contrôle d'intégrité du système de fichiers. Bien sûr, en réalité, tout cela est un peu plus compliqué. Comme le montre une discussion récente, cela pourrait même être plus confus que beaucoup d'entre nous ne le pensent, car l'assurance de l'intégrité des systèmes de fichiers journalisés impacte la performance.
Un système de fichiers tel que ext3 utilise une zone distincte sur le disque, appelée journal. Lorsqu'un changement est effectué dans les métadonnées du système de fichiers, ces modifications sont d'abord enregistrées dans le journal sans modifier le reste du système de fichiers. Après avoir enregistré tous les changements dans le journal, un « bloc de validation » y est ajouté, indiquant la fin de la transaction. Ce n'est qu'après l'enregistrement de ce bloc de validation que la transaction est validée et que les métadonnées modifiées sont écrites sur le disque. Si le système tombe en panne à un moment donné, les informations dans le journal peuvent être utilisées pour terminer le processus en toute sécurité et éviter des dégâts au système de fichiers à cause de la mise à jour partielle de métadonnées.
Cependant, il y a un hic : le code du système de fichiers doit être absolument certain que toutes les informations de la transaction ont déjà été écrites dans le journal avant d'écrire le bloc de validation. Il ne suffit pas d'enregistrer les opérations dans le bon ordre — les disques modernes prennent en charge de grands caches internes et réorganisent les opérations pour améliorer la performance. Ainsi, avant le bloc de validation, il est impératif d'indiquer explicitement le transfert de toutes les données du journal sur le disque. Si le bloc de validation est enregistré trop tôt, le journal peut être corrompu. Cette problématique est résolue à l'aide de barrières. En essence, une barrière interdit l'écriture de tout bloc après elle, jusqu'à ce que tous les blocs écrits avant la barrière soient déplacés sur le disque. En utilisant des barrières, les systèmes de fichiers garantissent la cohérence des structures de fichiers.
Cependant, il existe un autre problème : les systèmes de fichiers ext3 et ext4 n'utilisent pas par défaut les barrières. Une option est disponible, mais si l'administrateur ne les active pas explicitement, ces systèmes de fichiers fonctionnent sans barrières, bien que certains distributions (comme SUSE) aient des valeurs par défaut différentes. Eric Sandeen a récemment décidé qu'il fallait changer cette situation et , modifiant les réglages par défaut pour ext3 et ext4. Et alors, un débat animé a commencé.
Andrew Morton a expliqué en détail , pourquoi la valeur par défaut est telle :
La dernière fois que nous avons essayé de le changer, la performance sur de nombreuses charges a diminué de 30 %, donc j'ai horrifié jeté tous ces patchs. Je pense que nous ne pouvons pas nous permettre cela et ralentir le fonctionnement de toutes les machines de manière aussi significative…
Il n'existe pas de solutions idéales, et je penche pour ne pas éveiller ce chien qui dort et laisser les paramètres par défaut à la discrétion des développeurs de distributions.
Ainsi, par défaut, les barrières sont désactivées car elles ont un impact sérieux sur la performance. De plus, les systèmes de fichiers fonctionnent très bien sans barrières. Les rapports de corruption de système de fichiers ext3 sont peu nombreux et rares.
Mais ce n'est pas seulement de la chance. Ted Ts'o cela par le fait que le journal ext3 / ext4 est généralement placé de manière continue. Premièrement, le pilote de système de fichiers essaie de le rendre continu. Deuxièmement, le journal est généralement créé en même temps que le système de fichiers, lorsque l'espace continu est facile à trouver. La continuité et l'ordre sont utiles non seulement pour les performances, mais aussi pour éviter le réarrangement. En général, le bloc de validation sera placé immédiatement après les autres données dans le journal, donc le disque n'a pas de raison de réarranger. Le bloc de validation est naturellement écrit sur le disque immédiatement après les autres enregistrements du journal.
Cependant, personne ne prétend que cela sera toujours le cas. Les disques peuvent se comporter différemment. De plus, le journal est un tampon circulaire. Ainsi, lorsque la transaction est écrite à la fin du journal, le bloc de validation peut se retrouver dans un bloc antérieur, avant d'autres enregistrements du journal. Donc, il y a toujours une chance de corruption. En réalité, Chris Mason a des éléments de preuve pour cela. . Il ne fait aucun doute que travailler sans barrières est moins sûr que de le faire avec.
Si vous êtes prêt à accepter une diminution des performances, vous pouvez activer les barrières. Cela dit, cela ne s'applique que si votre système de fichiers n'est pas basé sur LVM (comme c'est le cas par défaut dans certaines distributions). Il s'avère que le device mapper ne prend pas en charge les barrières. Dans les autres cas, il serait bon de réduire la perte de performance. Et apparemment, cela peut être fait.
L'implémentation actuelle de ext3 (lorsque les barrières sont activées) exécute la séquence d'opérations suivante pour chaque transaction :
Les données sont écrites dans le journal
Une barrière est exécutée
Le bloc de validation est enregistré
La barrière suivante est exécutée
Plus tard, les métadonnées sont écrites sur le disque
Dans ext4, la première barrière (étape 2) peut être omise, car le système de fichiers ext4 prend en charge les sommes de contrôle dans le journal.
Si les données du journal et le bloc de validation sont réorganisés, et que l'opération est interrompue à cause d'un échec, alors la somme de contrôle du journal ne correspondra pas à celle stockée dans le bloc de validation, et la transaction sera annulée.
Chris Mason , qu'il serait « globalement sûr » de supprimer cette barrière aussi dans ext3, à l'exception possible lorsque le journal atteint la fin et commence à se réécrire depuis le début.
Une autre idée pour améliorer les performances est de retarder les opérations avec les barrières lorsque c'est possible. Si ce n'est pas urgent de flusher les données sur le disque immédiatement, plusieurs transactions peuvent être créées dans le journal et être écrites sur le disque avec une seule barrière.
Il y a également un potentiel d'amélioration en organisant soigneusement les opérations, de sorte que les barrières (qui sont généralement mises en œuvre sous forme de demandes « de flush toutes les opérations en attente sur le disque ») n'entraînent pas l'écriture de blocs qui ne nécessitent pas d'organisation.
Il semble qu'il soit temps de réfléchir à comment rendre le coût des barrières acceptable. Ted Ts'o semble :
Je pense que nous devons intégrer les barrières dans ext3/4, puis travailler à réduire les frais généraux dans ext4 / jbd2. Il est fort probable que la grande majorité des systèmes ne fonctionnent pas dans des conditions similaires à celles utilisées par Chris pour démontrer le problème, et la sécurité du système de fichiers par défaut doit être une priorité.
Le bon sens me dit que ce chien ne dort déjà plus et qu'il va probablement aboyer pendant un certain temps. Cela peut inquiéter certains voisins, mais c'est mieux que de le laisser mordre.
Intéressé à développer dans ce domaine ? Inscrivez-vous pour un cours Demo gratuit et participez à la diffusion , animée par Pavel Vikiryuk — opérateur de communication MVNO, ingénieur DevOps.
Source : habr.com
