[systemd-devel] [PATCH v2] journalctl: Improve boot ID lookup

[Lennart Poettering]

On Sat, 25.04.15 15:51, Jan Janssen (medhefgo at web.de) wrote:

> >Yeah, patches like these always do end up looking messy. It's much
> >easier to read after applying it.
> >
> >Well, it jumps from one boot to the next boot using _BOOT_ID matches. It
> >starts at the journal head to get the boot ID, makes a _BOOT_ID match
> >and then comes from the opposite journal direction (tail) to get the end
> >a boot. And then flushes the matches, and advances the journal from that
> >exact position one further (which gives us the start and ID of our next
> >boot). Rinse and repeat.
> >Note, v1 differs in that it assumes sd_journal_flush_matches() will also
> >reset the position we are in the journal at that moment. That version
> >went around that by using a cursor and seeking to the after flushing.
> >Hence why I wonder if this behavior of slush_matches is expected/desired
> >or not.
> >

Yes, _flush_matches() should exclusively flush the matches and not
reset the position. If it would change the position this would be a
bug. 

Matches really only change how we look for the next entry, not how we
look at the current one.

> I gave this another look today. Since journalctl uses SD_JOURNAL_LOCAL_ONLY
> by default, the new algorithm cannot trip up on interleaving boot IDs (since
> they shouldn't be interleaving in that case, per the above assumption). Same
> goes for --machine mode. Now, --file, --directory and --merge mode on the
> other hand does confuse the new algorithm.

Yeah, I think using the seek to boot id logic only really makes sense
for local journals. I think we should refuse operation if you mix
--merge (or the related other switches) with it.

> But I think it might be worth it to go with my above suggestion if that'll
> be accepted. Alternatively, we could either refuse --boot and --list-boots
> in those cases, or ship the old algorithm along with the new one and use
> that one in those cases where the faster one gets confused.
> 
> Or we stick with status quo and don't improve on the algorithm altogether.
> I'd like to know the option to go with, to ease me mind...

I think your altered algorithm does make a ton of sense, but please
add code that explicitly fails if you combine --boot with --merge and
so on...

Lennart

-- 
Lennart Poettering, Red Hat