我正在使用 Systemd 进行实验，特别是在具有 eMMC 存储的基于 Yocto Poky (Linux) 的嵌入式设备上尝试使用 Journald，但我担心闪存磨损，因为写入统计数据过高，如 /sys/block/mmcblk0/stat 所示和块跟踪。
注意：我希望在重新启动后保留日志，并且我正在使用journald/journalctl提供的结构化字段，因此具有系统日志转发的易失性日志似乎不可行，除非有办法保留附加字段。这就是说，我能只要高优先级消息成功，就可以在崩溃中丢失一些低优先级消息。
例如，每 8 秒记录几条简短的 DEBUG 消息的测试用例以 1.4 GB/天的速率写入 MMC，尽管消息本身仅为 5 MB/天（但请注意，用作journalctl -o export | wc指标会给出 125 MB） /day - 大概是由于元数据）。
该示例中有近 300 倍的写入乘法，这看起来非常高（我预计是 10 倍）。我想知道可以做什么来减少乘法因素？
blkparse output:
jbd2/mmcblk0p4- (180)
Reads Queued: 0, 0KiB Writes Queued: 33611, 134444KiB
Read Dispatches: 0, 0KiB Write Dispatches: 0, 0KiB
Reads Requeued: 0 Writes Requeued: 0
Reads Completed: 0, 0KiB Writes Completed: 0, 0KiB
Read Merges: 0, 0KiB Write Merges: 17722, 70888KiB
IO unplugs: 7835 Timer unplugs: 91
Allocation wait: 0 Allocation wait: 0
Dispatch wait: 0 Dispatch wait: 0
Completion wait: 0 Completion wait: 0
journal-offline (248, ...)
Reads Queued: 0, 0KiB Writes Queued: 6277, 46528KiB
Read Dispatches: 0, 0KiB Write Dispatches: 0, 0KiB
Reads Requeued: 0 Writes Requeued: 0
Reads Completed: 0, 0KiB Writes Completed: 0, 0KiB
Read Merges: 0, 0KiB Write Merges: 154, 3840KiB
IO unplugs: 563 Timer unplugs: 30
Allocation wait: 0 Allocation wait: 0
Dispatch wait: 0 Dispatch wait: 0
Completion wait: 0 Completion wait: 0
kworker/u2:0 (253, ...)
Reads Queued: 0, 0KiB Writes Queued: 32284, 288288KiB
Read Dispatches: 0, 0KiB Write Dispatches: 0, 0KiB
Reads Requeued: 0 Writes Requeued: 0
Reads Completed: 0, 0KiB Writes Completed: 0, 0KiB
Read Merges: 0, 0KiB Write Merges: 1351, 32744KiB
IO unplugs: 2553 Timer unplugs: 710
Allocation wait: 0 Allocation wait: 0
Dispatch wait: 0 Dispatch wait: 0
Completion wait: 0 Completion wait: 0
kworker/u2:1 (414, ...)
Reads Queued: 0, 0KiB Writes Queued: 28428, 260332KiB
Read Dispatches: 0, 0KiB Write Dispatches: 0, 0KiB
Reads Requeued: 0 Writes Requeued: 0
Reads Completed: 0, 0KiB Writes Completed: 0, 0KiB
Read Merges: 0, 0KiB Write Merges: 1256, 29428KiB
IO unplugs: 2290 Timer unplugs: 679
Allocation wait: 0 Allocation wait: 0
Dispatch wait: 0 Dispatch wait: 0
Completion wait: 0 Completion wait: 0
kworker/u2:2 (208, ...)
Reads Queued: 1, 4KiB Writes Queued: 22264, 200632KiB
Read Dispatches: 0, 0KiB Write Dispatches: 0, 0KiB
Reads Requeued: 0 Writes Requeued: 0
Reads Completed: 0, 0KiB Writes Completed: 0, 0KiB
Read Merges: 0, 0KiB Write Merges: 918, 21048KiB
IO unplugs: 1782 Timer unplugs: 481
Allocation wait: 0 Allocation wait: 0
Dispatch wait: 0 Dispatch wait: 0
Completion wait: 0 Completion wait: 0
systemd-journal (206)
Reads Queued: 13, 52KiB Writes Queued: 190, 508KiB
Read Dispatches: 0, 0KiB Write Dispatches: 0, 0KiB
Reads Requeued: 0 Writes Requeued: 0
Reads Completed: 0, 0KiB Writes Completed: 0, 0KiB
Read Merges: 4, 16KiB Write Merges: 0, 0KiB
IO unplugs: 128 Timer unplugs: 4
Allocation wait: 0 Allocation wait: 0
Dispatch wait: 0 Dispatch wait: 0
Completion wait: 0 Completion wait: 0
CPU0 (mmcblk0p4):
Reads Queued: 632, 61712KiB Writes Queued: 123054, 930732KiB
Read Dispatches: 8616, 61712KiB Write Dispatches: 101590, 930732KiB
Reads Requeued: 0 Writes Requeued: 0
Reads Completed: 8616, 61712KiB Writes Completed: 109579, 930732KiB
Read Merges: 4, 16KiB Write Merges: 21401, 157948KiB
Read depth: 2 Write depth: 9
IO unplugs: 15952 Timer unplugs: 2012
我尝试过的事情：
- 调整journald.conf中的SyncIntervalSec - 它似乎并没有对总数产生太大影响，只是对时间产生影响
- F2FS 而不是 ext4 - 实际上让它变得更糟，但我还没有尝试调整 mount/mkfs 参数（欢迎任何调整想法）
- sysctl vm.dirty_writeback_centisecs=0 - 这是因为我从 blktrace 注意到，大部分放大似乎来自日记脱机运行之间的 kworkers，大概是来自 Journald mmap() 使用？每天大约提供 400 MB，所以这是一个显着的改进，但我不确定 CRIT 消息是否仍然像 Journald 文档所说的那样立即同步
- https://github.com/systemd/systemd/pull/21183看起来可能会有帮助，但在稳定之前还有一段路要走
- fs 级压缩 - 结果尚不清楚，不确定这种方法是否能正确评估它？