Why not just have a SQLite file and call it a day?

Also, why mmaped file?

I'm not the architect of journald and wasn't really around when these decisions were made, so I can't really speak authoritatively on that particular topic.

There was mailing list discussion at the time journald was conceived though, you can find it if you look.

https://0pointer.de/blog/projects/the-journal.html might be a good entry-point.

▲

otterley 4 hours ago | parent | next [-]

The mailing list archives are here: https://lists.freedesktop.org/archives/systemd-devel/

It doesn't look like there was an open design review; Lennart Poettering just dropped it in in v38. https://lists.freedesktop.org/archives/systemd-devel/2012-Ja...

	▲	pengaru 4 hours ago \| parent [-]
		FWIW the journal file signature is "LPKSHHRH" for Lennart, Kay Sievers, Harald Hoyer, Red Hat... I presumed it was at least Lennart, Kay, and Harald who collaborated on the design.

▲

marginalia_nu 4 hours ago | parent | prev [-]

Well there was an ambition, apparently.

> Performance: journal operations for appending and browsing should be fast in terms of complexity. O(log n) or better is highly advisable, in order to provide for organization-wide log monitoring with good performance

> Minimal Footprint: journal data files should be small in disk size, especially in the light that the amount of data generated might be substantially bigger than on classic syslog.

▲

quotemstr 4 hours ago | parent | prev [-]

SQLite here is okay, but DuckDB or LevelDB would be better. Either way, no need to invent a new storage format.

▲

otterley 4 hours ago | parent | next [-]

Neither DuckDB nor LevelDB existed when journald was created. Not to say it couldn't be done today, but just some historical context.

▲

e2le 3 hours ago | parent | prev | next [-]

Sqlite3 is present in the default installation of most Linux distributions. It has proven itself from years of battle testing in many different environments. To use DuckDB or LevelDB would probably require pulling in an additional dependency.

▲

ElectricalUnion 4 hours ago | parent | prev [-]

No duckdb (or parquet). If you want to avoid writes and write amplification, you really want to avoid re-writing all 122880 rows of a row group every time a single insert happens.

	▲	quotemstr 4 hours ago \| parent [-]
		Uh, who said anything about writing 122880 rows every time you do a single insert into DuckDB? There's a WAL. Consolidation happens in big chunks. (And it's not like journald log rotation is somehow better than WAL consolidation.) We shouldn't be making momentus choices of data format based on vague and incorrect understandings of data formats.