Bug#832010: Please enable LZ4 compression

Yuri D'Elia wavexx at thregr.org
Thu Jul 21 23:28:24 BST 2016


On Fri, Jul 22 2016, Michael Biebl <biebl at debian.org> wrote:
> So, this is the main reason I'm worried about enabling lz4 support.
> Afair, it's not runtime configurable, so each new journal entry would be
> lz4 compressed, which effectively means we will have to use lz4 forever
> (which has quite a considerable worse compression).

Depending on the scenario, the performance of XZ might be inadequate
though.

For coredump I had to disable compression to avoid a nosedive in
performance at each crash. Even though LZ4 is not optimal, it still
makes a great difference compared to no compression, especially for core
files, and it's an "accepted" tradeoff for this kind of scenario.

I initially filed an RFE directly upstream to request LZ4, only to
discover it was already a new default but not available in debian.

> If lz4 support was runtime configurable and explicitly opt-in by the
> admin, I wouldn't be as concerned.

With the performance of XZ, I would be cautious to use it as the default
journal compression format either. journald is pretty [damn] slow
already without compression.

For an aggregation host maybe, but not for the current system.

> As it stands today, I don't want to make lz4 our new default.

I understand the concern. I similarly requested a tunable to select the
compression method, but I guess patches are the most welcomed request...

If somebody has the time, it doesn't look like a complicated task.
"compress.h" is very simplistic right now.

But I'd keep in mind that LZ4 seems to be a more reasonable choice
compared to XZ for both the journal and coredump.




More information about the Pkg-systemd-maintainers mailing list