Die Entwickler des Projekts systemd haben begonnen, ein langanhaltendes Architekturproblem im Komponenten "systemd-journald" zu untersuchen und zu beheben, das zu einer mehrfachen Erhöhung des auf die Festplatte geschriebenen Datenvolumens (Write Amplification) im Vergleich zum tatsächlichen Volumen der Protokolle führt.
Die Geschichte reicht zurück bis März 2020, als in dem Fehlerverfolgungssystem ein Bericht registriert wurde, der demonstrierte, dass die Generierung von etwa 500 KB Textprotokollen zu mehr als 700 MB physischen Schreibvorgängen auf SSD führte. Die Entwickler von systemd weigerten sich damals entschieden, das Problem anzuerkennen, antworteten im Stil "Sie verstehen nicht, wie Dateisysteme funktionieren", wiesen das Profiling zurück und schlossen das Ticket mit dem Urteil "not actionable". Die Kommentare der Entwickler erhielten Hunderte von negativen Bewertungen von Nutzern, doch die Position des Projekts blieb unnachgiebig.
Zu Beginn des Jahres 2026 wurde ein erneuter Bericht über das Problem eingereicht, in dessen Verlauf der unabhängige Entwickler ValdikSS ein detailliertes Profiling unter Verwendung isolierter cgroup- und Loop-Geräte durchführte, das anschaulich den Mechanismus des Problems beweiste: Aufgrund der Nutzung von in den Speicher gemappten Dateien (mmap) und binären Hash-Tabellen führt das Schreiben selbst einer einzigen Textnachricht von 750 Bytes zur Modifizierung von Fingerabdrücken im Speicher und verursacht einen Schreibvorgang von vollständigen 4-Kilobyte-Seiten auf die Festplatte, was zu 50 bis 70 KB Gesamteingaben/Ausgaben auf Blockgerät-Ebene führt.
Nachdem der Bericht über das Problem gestern auf die Hauptseite von Hacker News gelangte und unwiderlegbare synthetische Tests veröffentlicht wurden, änderten die Maintainer des Projekts ihre Rhetorik und begannen mit der Optimierung der Mechanismen für das Caching und der Struktur der Protokollindizes in journald.
Quelle: opennet.ru
