单条日志在 systemd-journald 磁盘写入中占用 49KB+ (ext4) / 110KB+ (btrfs) 的空间。

单条日志在 systemd-journald 磁盘写入中占用 49KB+ (ext4) / 110KB+ (btrfs) 的空间。
Single log line is 49KB+ (ext4) / 110KB+ (btrfs) of systemd-journald disk writes

原始链接: https://github.com/systemd/systemd/issues/40262

**问题摘要：systemd-journald 磁盘 I/O 过高** 用户反映在 Debian 13/XFS 系统（systemd-journald 版本 257.9）上，`systemd-journald` 存在严重的低效磁盘 I/O 问题。尽管日志记录量仅为每秒两条，系统却表现出约 50 IOPS 的负载。报告者认为，这种行为（此前在已关闭的 issue #15292 中已有记录）并非源于内核级的写入合并机制，而是 journald 文件格式本身固有的低效所致。此外，报告者还对文件体积膨胀及数据恢复能力不足表示担忧，指出在非正常重启后曾发生数据损坏。当前产生的 I/O 影响与其生成的日志量不成比例，远超传统 syslog 的性能表现。

近期的一场 Hacker News 讨论指出，`systemd-journald` 导致的磁盘写入放大问题引发了广泛关注。用户反馈称，单行日志可能触发 49KB 到 110KB 的磁盘写入，这会对固态硬盘（SSD）造成巨大磨损，尤其是在使用 Btrfs 等写时复制（COW）文件系统时。评论者批评 `journald` 的索引效率低下、性能不佳，且其二进制文件格式被认为“不可理喻”。许多人建议完全绕过它来存储日志，转而选择更简单、易于检索的文本替代方案。该帖作者 ValdikSS 将讨论范围扩大到了 `systemd` 之外，指出许多桌面应用程序存在过度且不必要的磁盘写入行为。他们的调查发现，包括 KDE 组件、Firefox 扩展和 IPFS 在内的常见工具，常因通知清除、着色器缓存或连接重试等微小任务而频繁写入磁盘。这种“喋喋不休”的运行方式导致了海量的累积数据写入，显著缩短了存储硬件的使用寿命。此次讨论也对现代软件设计进行了更广泛的批判，即开发者往往忽视了频繁、小规模磁盘 I/O 对性能及硬件的影响。

原文

systemd version the issue has been seen with

257.9

Used distribution

Debian 13

Linux kernel version used

6.12.57+deb13-amd64

Component

systemd-journald

Expected behaviour you didn't see

Log writes should be within order of magnitude of syslog

Unexpected behaviour you saw

VM doing ~50 IOPS when writing 2 lines of log per second

Steps to reproduce the problem

this is exactly same issue #15292 that was closed without good reason

Step 1. Use journald in mode where it writes to hard drive. The FS is XFS

Step 2. have constant stream of log entries going on a VM

Jan 03 13:37:01 cthylla haproxy[727]: 192.168.1.1:48550 [03/Jan/2026:13:37:01.392] f_www b_icinga/web 0/0/0/6/6 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
Jan 03 13:37:03 cthylla haproxy[727]: 192.168.1.1:36892 [03/Jan/2026:13:37:03.403] f_www b_icinga/web 0/0/0/7/7 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
Jan 03 13:37:05 cthylla haproxy[727]: 192.168.1.1:36904 [03/Jan/2026:13:37:05.416] f_www b_icinga/web 0/0/0/6/6 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
Jan 03 13:37:07 cthylla haproxy[727]: 192.168.1.1:36906 [03/Jan/2026:13:37:07.427] f_www b_icinga/web 0/0/0/6/6 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
Jan 03 13:37:09 cthylla haproxy[727]: 192.168.1.1:36912 [03/Jan/2026:13:37:09.439] f_www b_icinga/web 0/0/0/7/8 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
Jan 03 13:37:11 cthylla haproxy[727]: 192.168.1.1:36918 [03/Jan/2026:13:37:11.454] f_www b_icinga/web 0/0/0/6/6 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
Jan 03 13:37:13 cthylla haproxy[727]: 192.168.1.1:45832 [03/Jan/2026:13:37:13.465] f_www b_icinga/web 0/0/0/7/7 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
Jan 03 13:37:15 cthylla haproxy[727]: 192.168.1.1:45848 [03/Jan/2026:13:37:15.476] f_www b_icinga/web 0/0/0/6/6 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
Jan 03 13:37:17 cthylla haproxy[727]: 192.168.1.1:45856 [03/Jan/2026:13:37:17.488] f_www b_icinga/web 0/0/0/6/6 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"
Jan 03 13:37:19 cthylla haproxy[727]: 192.168.1.1:45862 [03/Jan/2026:13:37:19.500] f_www b_icinga/web 0/0/0/6/6 302 153 - - ---- 2/2/0/0/0 0/0 "GET / HTTP/1.0"

Step 3. Observe the VM IO traffic.

I used VM as example because the complaint in #15292 was "iotop is not accurate" (I can believe that, it's before any OS write coaelscing) but this clearly shows traffic after every kernel mechanism was used. So no, it isn't "kernel making lotsa iops out of it", it's slow.

Journald just uses extremely inefficient format (also I've seen it corrupt on unclean reboot enough times to declare it's not even all that resilient) as files are also multiple times the size of what's actually written in them.