[rnhmjoj]

I think the issue is not that it's binary, but that it's a custom half-assed format. It's actually pretty slow because there is not enough indexing, this is why `systemctl status` can takes seconds to show the last 10 log lines[1]. Even worse, systemd can detect corruption but can't repair the logs[2], in practice a power failure can mean months of logs thrown away. Thankfully it can skip over corruption, so logging continues to work.

I would have no problem if systemd used a database like sqlite, lmdb or anything else with some valid tooling, indexing, caching and proper recovery solutions.

[1]: https://github.com/systemd/systemd/issues/2460

[2]: https://unix.stackexchange.com/questions/86206

[zxzax]

I looked into this a while ago -- a traditional transactional CRUD database is totally unnecessary here, these are not files that you want to be editable by random tools. The journald log files have the important property that they are append-only by a single-writer. I agree there are some outstanding issues but those issues should just be fixed, instead of throwing it all out and moving to an even more complicated database layer that brings with it all its own additional problems. I think it would be perfectly feasible for someone to improve the indexing to show the latest 10 lines, or to write a fsck-type tool to repair damaged logs.

[throw0101a]

> instead of throwing it all out and moving to an even more complicated database layer that brings with it all its own additional problems.

Would SQLite be any more complicated than what they have now? Or OpenLDAP's Lightning Memory-Mapped Database (LMDB)? OpenLDAP/Symas' Howard Chu on the latter:

* https://www.linkedin.com/pulse/20140924071300-170035-why-you...