A GitHub issue documents excessive disk I/O caused by systemd-journald, where writing a single short log message results in tens of kilobytes of physical disk writes, far more than a comparable syslog write to a text file. Users report VMs and desktops experiencing IO spikes up to 100%, with journald logging 'Under memory pressure, flushing caches' and one machine writing nearly 7GB in 15 minutes. Detailed testing with block-stat and cgroup io.stat instrumentation shows journald's mmap-based on-disk format is verbose, unindexed, and writes to persistent storage on every log line rather than batching, with SyncIntervalSec only controlling fsync timing, not the write itself. Commenters, including a self-described kernel developer, argue the fundamental design choice of using mmapped writes instead of pwrite is flawed and question why journald relies on it. Workarounds discussed include disabling compression, switching to volatile storage, and enabling ext4 lazytime/noatime.
Table of contents
systemd version the issue has been seen withUsed distributionLinux kernel version usedComponentExpected behaviour you didn't seeUnexpected behaviour you sawSteps to reproduce the problemQuestions this post answers
Why does systemd-journald cause so much more disk IO than plain syslog for the same log messages?
Journald writes to its mmap-backed persistent journal file on every log entry, not just periodically, because SyncIntervalSec only controls the fdatasync/fsync delay, not when data is actually written to disk. Testing on ext4 showed a single short log entry (about 752 bytes of journal data) produced over 55 KB of physical block writes, versus about 21 KB total for 3 similar syslog appends using fdatasync+fsync, because the on-disk format is verbose, duplicates fields like boot ID per entry, and is not compactly indexed. Developers tuning logging pipelines can track journald IO debates like this one on daily.dev.
How can I reduce disk writes caused by systemd-journald on a system where I don't need persistent logs?
Set Storage=volatile in the [Journal] section of journald.conf so logs are kept in memory instead of being written to persistent disk files, eliminating the excessive writes tied to journald's mmap-based persistent storage. Other partial mitigations discussed include disabling compression, though testers found it made no meaningful difference for short log entries. daily.dev helps sysadmins keep up with practical fixes for logging-related IO issues like this.