Les développeurs du projet systemd ont commencé à étudier et à résoudre un ancien problème architectural dans le composant « systemd-journald », entraînant une amplification d'écriture des données sur disque par rapport au volume réel des journaux.
L'histoire remonte à mars 2020, lorsque dans le système de suivi des erreurs, un rapport a été enregistré démontrant que la génération d'environ 500 Ko de journaux textuels entraînait plus de 700 Mo d'opérations d'écriture physiques sur SSD. À l'époque, les développeurs de systemd ont catégoriquement refusé de reconnaître le problème, répondant dans le style 'vous ne comprenez pas comment fonctionnent les systèmes de fichiers', ont refusé de procéder à un profilage et ont fermé la demande avec un verdict 'not actionable'. Les commentaires des développeurs ont récolté des centaines d'évaluations négatives de la part des utilisateurs, mais la position du projet est restée inflexible.
Début 2026, un rapport sur le problème a été soumis à nouveau, durant la discussion, un développeur indépendant ValdikSS a réalisé un profilage détaillé en utilisant des cgroups isolés et des dispositifs loop, prouvant clairement le mécanisme de survenance du problème : en raison de l'utilisation de fichiers mappés en mémoire (mmap) et de tables de hachage binaires, l'écriture même d'un seul message texte de 750 octets entraîne la modification des empreintes en mémoire, provoquant un déversement sur disque de pages complètes de 4 Ko et générant entre 50 et 70 Ko de I/O finale au niveau du dispositif de bloc.
Après que le rapport sur le problème ait atteint la page d'accueil de Hacker News hier et la publication de tests synthétiques irréfutables, les mainteneurs du projet ont modifié leur rhétorique et ont commencé à travailler sur l'optimisation des mécanismes de vidage de cache et de la structure de stockage des index journald.
Source : opennet.ru
