单条日志行会导致 49KB+（ext4）/ 110KB+（btrfs）的 systemd-journald 磁盘写入
Linux 管理员报告称 systemd‑journald 会带来极端的写放大：在 ext4 和 Btrfs 等文件系统上，一条日志记录就可能触发数十 KB 的磁盘写入，这让人担心 SSD 寿命和性能。评论者将其归因于 journald 基于 mmap、带哈希索引的二进制日志格式，以及其大量修改磁盘内容的设计，认为它更像一个设计欠佳的数据库，而不是简单的追加式日志。许多人建议通过限制或卸载 journald 的存储来缓解，或用传统 syslog / 数据库支持的日志系统替代，同时质疑这样一个关键组件为何不直接采用现成且经过实战检验的存储引擎。
磁盘写放大与影响
- systemd‑journald 中的一条日志条目就可能触发数十到数百 KB 的磁盘写入，尤其是在 btrfs 上，造成严重的写放大。
- CoW 文件系统（btrfs，以及其他文件系统）会放大这一问题，导致主要处于空闲状态的桌面系统也产生大量累计 SSD 写入。
- 许多其他桌面应用和服务（KDE 组件、浏览器扩展、IPFS、Redis 等）也会频繁写入，进一步加剧这一问题。
对 journald 设计与行为的批评
- 磁盘格式被认为过于复杂：分散的小写入、哈希表更新以及 mmap 的使用带来了额外 IO 和较差的扩展性。
- 多位评论者表示，使用
journalctl读取日志比 grep 纯文本日志（即使是 gzip 压缩后的）还要慢。 - 有人反馈 journald 很脆弱（日志损坏、过去的 watchdog 问题），而且难以调试或推理。
- 过滤和限流被认为比较粗糙：很难只静音某一个噪声源而不影响其他源；虽然存在按服务的模式，但能力有限且不一致。
关于 mmap、数据库与格式的争论
- 对把可写 mmap 用于日志的批评很强烈：对刷盘顺序几乎没有控制、按页粒度弄脏、在复杂文件系统上的行为不可预测。
- 也有人认为 mmap 并非天生有问题，只要配合谨慎的刷盘策略；另一些人则认为这只是一个不必要的“花哨技巧”。
- 有多种提议建议使用现有存储引擎而不是自定义格式：SQLite、DuckDB、LevelDB、Parquet，或者简单的仅追加文本加离线索引。
- 对 WAL/LSM 方案存在分歧：有人指出 WAL 会让写入翻倍；也有人认为它仍然比 journald 当前的模式更有原则、效率也更高。
关于 systemd 生态与治理的担忧
- journald 经常被称为 systemd 最糟糕的部分；许多人会保留 systemd，但如果 journald 真正可选，就会替换掉它。
- 有人批评 systemd 没有宣传中那么模块化，因为 journald 实际上是强制性的。
- 还有对项目文化的抱怨：对 bug 报告的防御性回应、缺乏开放的设计评审、倾向于重新发明而不是复用经过验证的组件。
变通办法与替代方案
- 常见缓解措施包括：
Storage=volatile、设置较小的大小限制，或只把 journald 作为路由器，而使用 rsyslog/syslog‑ng 或外部收集器保存日志。 - 一些用户转向非 systemd 发行版（Devuan、Void）或其他操作系统（如 FreeBSD），部分原因是为了避开 journald。
- 还有建议在 btrfs 上将某些路径标记为
nocow，并在可行时更积极地过滤或黑名单化噪声日志消息。