systemd-journald bug filed: single log line produces 49KB+ on ext4, 110KB+ on btrfs disk writes

The concrete event here is the filing of systemd GitHub issue #40262, opened by user XANi on January 3, 2026 against the systemd-journald component in systemd 257.9. The reported environment is Debian 13 running kernel 6.12.57+deb13-amd64, and the issue is labelled as a bug with no assignee, no milestone and no linked branches or pull requests, so there is no patch or maintainer response in the material to report on.

The headline-level claim carried by the sole feed, Hacker News, is that a single log entry results in 49KB+ of disk writes on ext4 and 110KB+ on btrfs. The issue body itself uses a different framing: the reporter observed a VM sustaining around 50 IOPS while producing only two log lines per second from haproxy, and argues the cause is journald's on-disk format rather than any kernel write-coalescing effect. The two descriptions are consistent in direction (writes are far larger than the input) but the specific byte figures are not stated in the extracted issue body, so they should be read as the HN thread's framing of the report rather than numbers pulled from the issue text itself.

The reporter's own diagnosis is that journald 'uses extremely inefficient format' and produces files that are 'multiple times the size of what's actually written in them'. They also claim to have seen journald files corrupt on unclean reboot often enough to question its resilience. None of this is corroborated by maintainer comments in the material; it is the reporter's stated view, and the issue is open and unaddressed as far as the extract shows.

For an engineer reading the headline in isolation, the practical implication is that if the numbers hold, systems forwarding even modest log volumes through journald to ext4 or btrfs could be amplifying write traffic by orders of magnitude, which matters for flash wear, IOPS budgets in virtualised environments, and noisy-neighbour effects on shared storage. The material does not contain a reproduction procedure beyond the reporter's steps, no benchmark methodology, and no second source reproducing the btrfs or ext4 byte counts, so this is a single report rather than a confirmed regression.

The most useful thing the material does contain is the link to prior issue #15292, which the reporter says was closed without justification. The implication is that this is at least the second time the same write-amplification behaviour has been raised against journald, and the absence of a fix or maintainer acknowledgement in the new issue means the status quo is unchanged as of the material's date. Any team relying on journald for persistent logs on ext4 or btrfs should treat this as a heads-up to measure their own write traffic rather than a confirmed actionable defect.