Die Entwickler des Projekts systemd haben begonnen, ein seit langem bestehendes architektonisches Problem im Modul „systemd-journald“ zu untersuchen und zu beheben, das zu einer erheblichen Steigerung der auf die Festplatte geschriebenen Datenmenge (Write Amplification) im Vergleich zum tatsächlichen Logvolumen führt.
Die Geschichte reicht bis März 2020 zurück, als in der Fehlerverfolgung ein Bericht registriert wurde, der zeigte, dass die Generierung von etwa 500 KB Textlogs in über 700 MB physischer Schreibvorgänge auf SSDs resultierte. Die Entwickler von systemd weigerten sich damals hartnäckig, das Problem zu erkennen, entgegneten im Stil „Sie verstehen nicht, wie Dateisysteme funktionieren“, lehnten eine Profilerstellung ab und schlossen die Anfrage mit dem Urteil „not actionable“. Die Kommentare der Entwickler erhielten Hunderte von negativen Bewertungen von Benutzern, doch die Haltung des Projekts blieb unerschütterlich.
Anfang 2026 wurde ein erneuter Bericht über das Problem eingereicht, in dessen Verlauf der unabhängige Entwickler ValdikSS eine detaillierte Profilierung mit isolierten cgroup- und Loop-Geräten durchführte, die den Mechanismus der Problemverursachung eindrucksvoll belegte: Aufgrund der Verwendung von in den Speicher abgebildeten Dateien (mmap) und binären Hash-Tabellen führt das Schreiben selbst einer einzigen Textnachricht von 750 Byte zu Änderungen an den Abbildungen im Speicher, was zu einem vollständigen 4-Kilobyte-Seitenabgleich auf der Festplatte führt und von 50 bis 70 KB endgültigem I/O auf Blockgerätsebene generiert.
Nach der gestrigen Veröffentlichung des Problemberichts auf der Startseite von Hacker News und der Veröffentlichung unumstößlicher synthetischer Tests änderten die Macher des Projekts ihre Rhetorik und begannen mit der Optimierung der Mechanismen für das Caching und die Struktur der Speicherung von Journald-Indizes.
Quelle: opennet.ru
