Re: Journald's qualities
On Fri, Feb 23, 2024 at 10:17 PM The Wanderer <wanderer@fastmail.fm> wrote:
>
> On 2024-02-23 at 15:35, Stefan Monnier wrote:
>
> >>> but what are the advantages of journald's representation compared
> >>> to a naive one?
> >>
> >> in short: querability without text parsing. That's about it.
> >
> > They have to parse the binary format, so that's not in and of itself
> > an upside compared to parsing CSV.
> >
> > I've made my share of bad design decisions that don't pan out. But
> > there's always an upside to my decision (even when it turns out it
> > speeds up only those cases which can never occur, because of some
> > other aspect of the system).
> >
> > AFAICT the format is *not* just a plain sequence of log entries, so
> > there's some additional structure which is intended to speed up some
> > operations.
> >
> > IOW, even if contrived, there should be *some* use case where it
> > does better than CSV, no?
>
> I can think of two possibilities, just offhand, in no particular order:
>
> * No need to parse the timestamps, et cetera, and take the risk that
> someone put in one that's in a format you don't expect; the times are
> stored internally in a consistent guaranteed format, so you can just use
> internal reader functions (paired with, and updated alongside, the
> internal writer functions) and be done with it.
>
> * No need to worry about handling log entries that *contain* commas, or
> whatever other element was chosen as the separator.
Systemd also provides tamper-resistant logs. The property is often
desirable in the enterprise. See Forward Secure Sealing,
<https://lwn.net/Articles/512895/>.
Jeff
Reply to: