Single log line is 49KB+ (ext4) / 110KB+ (btrfs) of systemd-journald disk writes

The strongest technical explanation came from someone who previously worked on making journald usable. The claim is that the on-disk format spreads each entry’s metadata and indexes across many small, non-contiguous updates inside one file. That means each little logical update can dirty whole filesystem blocks or memory pages. Using mmap for writes likely makes the pattern worse by dirtying page-sized regions and polluting the page cache. People connected that directly to journald’s design goal mismatch. It was supposed to be compact despite richer metadata, but the current structure behaves more like a small random-write database than an append-only log. That framing pushed the conversation past the usual "systemd bad" reflex. The practical point was not that binary logs are inherently flawed or that databases are always wrong. It was that journald picked the worst possible write path for a logger. Several people said the workload wants an append-only or append-mostly design, with indexing deferred or batched. Others argued that if you really want queryable structured logs, use a storage engine built for that instead of a custom format. At the same time, a few commenters defended the original idea. Fielded queries are genuinely useful, and plain grep over text is still an O(N) scan. But even those defenders conceded that the current tradeoff makes less sense now that serious indexing usually happens off-host in Loki, Elasticsearch, Splunk, or similar systems. A second theme was that journald’s operational controls are weak where people most need them. When a buggy driver, desktop component, or container stack starts spewing logs, you often cannot surgically cap or filter that source in journald itself. Newer systemd versions added LogFilterPatterns for services, but people described it as narrow and awkward. It does not help with kernel spam and does not cover every source. That leaves admins falling back to volatile storage, forwarding to rsyslog, or patching around noisy components one by one. The broader lesson was that write amplification is only half the problem. The other half is a logging stack that gives too little control once software starts misbehaving.