当我做某事时，journalctl --disk-usage它会说一些关于300MB日志文件的大小，但当我查看实际的文本时，journalctl | wc -c我发现28MB嗯，journald 有压缩功能，即使考虑到时间戳、uid、消息哈希等元数据，在我看来这也浪费了大量磁盘空间。
有人能告诉我为什么日志文件与里面的实际文本相比这么大吗？
答案1
有两个原因。首先，正如@Mella 提到的，当前日志与所有日志之间存在差异。
其次，如 中所述man journalctl，有多种输出格式。您正在测量最紧凑/最不详细的大小。要查看 systemd 日志中的最大数据，请使用：
journactl --output=verbose
在我的例子中，紧凑日志输出返回 32MB 数据，而 则返回 128MB 数据--output=verbose， 则找到 152MB 数据journalctl --disk-usage，涵盖活动日志和存档日志。
如果您担心的话，请参阅man journald.conf如何限制磁盘空间的使用量。journald
答案2
- 它们很大，因为它是一种错误：
正如所指出的上游因此 journald 的开发人员知道，所使用的二进制日志格式并不是很好（目前为止？）。
- 它们很大，因为可能没有激活压缩
/etc/systemd/journald.conf在named中还有一个选项Compress=yes，它可能在您的系统上未处于活动状态，因此实际上没有压缩。
- 存档期刊的问题在这里并不重要。
虽然原则上 journald 确实区分了积极的和已归档日志记录，这是对其他答案的误导性回复，因为man journalctl它明确指出：
输出是来自所有可访问日志文件的交错，无论它们是旋转的还是当前正在写入的，也不管它们是属于系统本身还是可访问的用户日志。
因此，其他答案在这里具有误导性。
- 由于一些文件分配、碎片、防损坏措施，journalctl 的磁盘使用量巨大（即大于具有同等信息级别（即字段）的纯文本文件）。
“文件碎片/分配问题”
在我的机器上，journalctl --version == "systemd 239[...]"包含数据的日志文件的文件大小是 8MiB 的倍数。因此，在我的系统日志文件中，即使实际存储的数据只有一小部分（例如 56kiB），其大小也会达到 8MiB。
journald“反腐败问题” 据 的开发人员之一Poettering 称，systemd如果期刊被认为已被 破坏journald，则不会对其进行“修复”，而是保持原样，以防止进一步出现问题。（见https://bugs.freedesktop.org/show_bug.cgi?id=64116#c3）
这当然意味着未压缩的、几乎为空的日志二进制日志文件很有可能存在于您的 var 日志中，这使得它实际上比合理的纯文本替代方案要大得多。
答案3
journalctl没有参数（使用其输出进行测量wc -c）仅显示活动日记帐中的日记帐分录（我不确定是什么促使了周转）。journalctl --disk-usage显示存档日记帐和活动日记帐使用的空间。