On Fri, Jul 22 2016, Michael Biebl <bi...@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.
