The systemd project developers have begun studying and fixing a long-standing architectural issue in the "systemd-journald" component that causes the amount of data written to disk (write amplification) to be significantly higher than the actual volume of logs.
The story dates back to March 2020, when a report was filed in the bug tracking system demonstrating that generating approximately 500 KB of text logs resulted in over 700 MB of physical write operations on SSDs. The systemd developers flatly denied the problem, responding with a "you don't understand how filesystems work" response, refusing to conduct profiling, and closing the ticket with a verdict of "not actionable." The developers' comments garnered hundreds of downvotes from users, but the project's stance remained unwavering.
In early 2026, a second issue report was submitted, during which independent developer ValdikSS performed detailed profiling using isolated cgroup and loop devices, clearly demonstrating the mechanism by which the issue occurs: due to the use of memory-mapped files (mmaps) and binary hash tables, writing even a single 750-byte text message results in modification of memory fingerprints, causing full 4-kilobyte pages to be flushed to disk and generating 50 to 70 KB of resulting I/O at the block device level.
Following yesterday's Hacker News front-page report and the publication of irrefutable synthetic tests, the project's maintainers have changed their rhetoric and begun working on optimizing journald's cache flushing mechanisms and index storage structure.
Source: opennet.ru
