Administrace komentářů

Jo, to netuším, co je špatně. Přičiním jenom několik „stating the obvious“ poznámek:

• Zazipovaný textový soubor nemá ani náznak indexování nebo jiné podpory rozumně rychlého přístupu k logům podle -u nebo podle času, takže se nedá srovnat 1:1 s tím, co ukládá journald.
• Pokud mě man journald.conf neklame, implicitně se komprimují jen záznamy (== jednotlivé „zprávy“ v logu, velikostí něco mezi „řádkou“ a „backtrace“ ), pokud přesáhnou 512 B. Tohle se sice dá nastavit (snížit), ale pokud má každý záznam svůj oddělený kontext/slovník pro kompresi, bude taková komprese velmi neúčinná.
• Pokud je uschopněný Seal= (FSS), což v některých distrech může být implicitně nastavené při instalaci, bez vědomého přičinění uživatele, můžou data logů ještě víc nabobtnat.
• Čtení všeho z /var/log/journal není příliš fair srovnání, protože tam je uložené všechno z journalctl + všechno z journalctl --user + všechno z journalctl --user pro všechny ostatní uživatele.
• Dokonce i bez FSS budou mít soubory s logy nějaké svoje extra checksumy. (Nevím, jak časté a s jakým overheadem.)

Ještě pro upřesnění, co jsem myslel tímto:

A ne, podstatná část diskového prostoru se opravdu (ale opravdu (ale opravdu)) neuvolní zkrácením (binárních, komprimovaných) logů.

Výše zmíněné checksumy zajistí, že poškození (náhodné zkrácení) binárních logů od journald učiní tyto soubory nečitelnými. Tudíž místo předvídatelného zkrácení dojde ke ztrátě dat z podstatné části příslušného souboru (výrazně větší než uříznutá část), popřípadě z celého souboru, který může journalctl odmítnout číst. A při každém přístupu přes journalctl se bude ukazovat chybová hláška o poškozeném souboru.

Proto↑ jsem příslušnou „radu“ považoval za kolosální nesmysl. Měl jsem se vyjádřit přesněji.