2 min read
In short
Excessive writes by systemd-journald have been discussed for years, but the consequences are easy to miss: ordinary logging can put a noticeable load on the drive. I look at why this happens and what turning persistent logs off actually costs.
Logs can quietly become one of the busiest consumers of an SSD. Six years on, systemd-journald has acknowledged the problem: the service creates excessive writes to the drive because of write amplification — the actual volume written turns out larger than the volume of the journals themselves.
The problem was first discussed back in 2020. One test reported that when around 500 MB of data appeared, journald wrote roughly 700 MB to the SSD. On an ordinary computer that may look like a trifle, but for systems on eMMC, NAND, MicroSD or drives whose write endurance matters it already becomes an unwelcome signal.
The cause is not only the number of messages. journald works with journal files through mmap, and under certain scenarios, including load inside a cgroup and work with loop devices, writes can generate extra disk traffic. In the end the monitoring meant to help diagnose the system becomes a source of load itself.
And what matters here is not the fact of an old bug but the support model. According to the source, the original report was deemed insufficiently actionable and closed as not actionable. Years later new experiments showed the problem again — this time in scenarios where the excess writing can be especially noticeable.
The limitation of the simple workaround is obvious: the discussion advises setting Storage=volatile in /etc/systemd/journald.conf. That moves journals into RAM and reduces disk writes, but after a reboot there will be no persistent logs. On top of that, some of the ability to view user journals and split data per user loses its point in this mode. So disabling on-disk journalling blindly on a server is not an option either: SSD endurance is traded for the risk of losing the data needed to investigate a failure.
The practical takeaway is simple: journald is worth treating not as a free background service but as a consumer of disk endurance. If a system runs on a weak or worn drive, check the real volume of writes and decide in advance which matters more — keeping journals across reboots, or the minimum load on the SSD.
Would you sacrifice persistent logs for the sake of drive endurance if the system runs on eMMC or MicroSD? Source: OpenNews.opennet.ru: General news feed