[systemd-devel] Plans to fix or provide alternative for lz4?
shawnlandden at gmail.com
Mon Mar 2 11:15:28 PST 2015
On Sun, Mar 1, 2015 at 3:04 AM, Lennart Poettering <lennart at poettering.net>
> On Thu, 26.02.15 05:55, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl)
> > On Thu, Feb 26, 2015 at 04:41:48AM +0000, Laszlo Papp wrote:
> > > Hi,
> > >
> > > it seems that the lz4 headers are broken when getting coredumps
> > > generated. They cannot even be extracted by the lz4 tool itself, let
> > > alone using them via the coredump controller util.
> > >
> > > My system, which is Archlinux, is using lz4 127 and systemd 219.
> > >
> > > My current workaround was to disable compression altogether for
> > > coredumps in the corresponding config file, but it is suboptimal,
> > > especially on embedded systems.
> > The headers are different because when lz4 support was added, lz4 did
> > not provide a library to write the headers so I added custom headers.
> > You should be able to use coredumpctl to unpack the file.
> > "Proper" lz4 support has been written, but lz4 upstream has trouble
> > with keeping .so compatibility:
> > So the question is whether to replace lz4 with something more stable
> > or to ignore the issue and hope it doesn't happen again.
> Maybe gzip might be a good compromise? Due to the importd logic we now
> check for libz anyway in configure.ac, we might as well use it for the
> journal. To my knowledge gzip is still a good compromise between
> compression ratio on one hand and memory use/time on the other...
except xz beats gzip at its lower compression settings even on memory
use/time. See man 1 xz.
> Lennart Poettering, Red Hat
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the systemd-devel