systemd-journald turns one log line into 49KB–110KB of disk writes

A newly filed systemd issue (#40262) argues that journald’s on-disk logging is wildly inefficient. The reporter, running systemd 257.9 on Debian 13 with kernel 6.12, measured roughly 50 disk IOPS on a VM that was only emitting about two log lines per second. Each modest log entry — the example is a routine HAProxy access line — expands into 49KB or more of writes on ext4 and over 110KB on btrfs, orders of magnitude beyond what a comparable syslog setup would produce.

The filer frames this as a reopening of issue #15292, which was closed on the grounds that measurement tools like iotop sit above the kernel’s write-coalescing layer and therefore overstate real IO. This report tries to preempt that objection by measuring at the VM level, after every kernel-side coalescing mechanism has run, and still sees heavy traffic. The conclusion offered is that journald itself is slow, not the kernel amplifying small writes.

Beyond raw throughput, the complaint targets the journal’s binary format: files reportedly occupy several times the space of the data they actually hold, and the reporter says they’ve seen journals corrupt after unclean reboots often enough to doubt the format’s resilience. Whether maintainers accept the framing or again attribute the numbers to measurement artifacts, the issue revives a long-running debate over whether structured, indexed journald logging carries an IO and durability cost that plain syslog avoids.