Les développeurs du projet systemd ont commencé à étudier et à corriger un problème architectural de longue date dans le composant « systemd-journald » qui fait que la quantité de données écrites sur le disque (amplification d'écriture) est significativement plus élevée que le volume réel des journaux.
L'affaire remonte à mars 2020, lorsqu'un rapport a été déposé dans le système de suivi des bogues, démontrant que la génération d'environ 500 Ko de journaux texte entraînait plus de 700 Mo d'opérations d'écriture physique sur les SSD. Les développeurs de systemd ont catégoriquement nié le problème, répondant par un « vous ne comprenez pas le fonctionnement des systèmes de fichiers », refusant d'effectuer un profilage et clôturant le ticket avec la mention « non exploitable ». Leurs commentaires ont récolté des centaines de votes négatifs, mais la position du projet est restée inflexible.
Début 2026, un deuxième rapport de problème a été soumis, au cours duquel le développeur indépendant ValdikSS a effectué un profilage détaillé à l'aide de périphériques cgroup et loop isolés, démontrant clairement le mécanisme par lequel le problème se produit : en raison de l'utilisation de fichiers mappés en mémoire (mmaps) et de tables de hachage binaires, l'écriture d'un seul message texte de 750 octets entraîne une modification des empreintes de mémoire, provoquant le vidage de pages complètes de 4 kilo-octets sur le disque et la génération de 50 à 70 Ko d'E/S résultantes au niveau du périphérique de bloc.
Suite à l'article paru hier en première page de Hacker News et à la publication de tests synthétiques irréfutables, les responsables du projet ont changé de discours et ont commencé à travailler sur l'optimisation des mécanismes de vidage du cache et de la structure de stockage des index de journald.
Source: opennet.ru
