The developers of the systemd project have begun investigating and addressing a long-standing architectural issue in the "systemd-journald" component that leads to a significant write amplification compared to the actual log size.
The story dates back to March 2020, when a report was filed in the bug tracking system demonstrating that generating around 500 KB of text logs resulted in over 700 MB of physical write operations on an SSD. The systemd developers categorically refused to acknowledge the issue, responded with claims like "you don't understand how file systems work," declined to conduct profiling, and closed the request with a verdict of "not actionable." Developer comments received hundreds of negative ratings from users, but the project's stance remained firm.
In early 2026, a follow-up report on the issue was submitted, during which independent developer ValdikSS conducted detailed profiling using isolated cgroups and loop devices, clearly demonstrating the mechanism behind the problem: due to the use of memory-mapped files (mmap) and binary hash tables, writing even a single text message of 750 bytes results in modifications to memory fingerprints, causing a flush to disk of entire 4-kilobyte pages and generating 50 to 70 KB of total block device I/O.
After the report about the issue made it to the front page of Hacker News yesterday and the publication of irrefutable synthetic tests, the project's maintainers changed their rhetoric and began working on optimizing the cache flush mechanisms and the storage structure of journald indexes.
Source: opennet.ru
