On Sat, 25.04.15 15:51, Jan Janssen (medhe...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel