> [13:37:48]cthulhu:/var/log/journal☠journalctl |dd of=/dev/zero bs=1M
> 0+15442 records in
> 0+15442 records out
> 63643115 bytes (64 MB, 61 MiB) copied, 5,47791 s, 11,6 MB/s
> du -h /var/log/journal/
> 337M /var/log/journal/44cf6f547971fc33309d1e9e000002e7
> 337M /var/log/journal/
>
> (I've raised a bug 8 years ago about it
> https://github.com/systemd/systemd/issues/2460 )
Oh, that bug report is quite interesting, thanks.
Makes one wonder why they don't use naive append-only "plain text" logs
(tho with appropriate delimiters (maybe some kind of CSV) to make
searches more reliable than with old-style plain text logs)?
What are the advantages of journald's representation?
I mean, to justify the slow search and large disk space usage, there is
presumably some upside for some use cases. I can see some weak argument
against Sqlite based on the size of Sqlite, but what are the advantages
of journald's representation compared to a naive one?
Stefan
PS: FWIW, the only time I thought about the design of a log format,
I was thinking along the lines of reducing redundancy, i.e. keeping
a kind of "suffix tree" of past messages so as to replace the many
repeated chunks of text with references to past log entries.
Then I realized that I could get the same result much more simply by
gzipping the files, which would naturally be done as part of
log rotation 🙂
