On Sat, Aug 30, 2014 at 10:13:43AM +0300, Evangelos Foutras wrote:
> We can't use LZ4_compress_limitedOutput_continue() because in the
> worst-case scenario the compressed output can be slightly bigger than
> the input block. This generally affects very few blocks and is no reason
> to abort the compression process.
Applied.
We should probably do the same for XZ.
Zbyszek
> I ran into this when I noticed that Chromium core dumps weren't being
> compressed. After switching to LZ4_compress_continue() a ~330MB Chromium
> core dump gets compressed to ~17M.
> ---
> src/journal/compress.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/journal/compress.c b/src/journal/compress.c
> index 52a4c10..c4c715b 100644
> --- a/src/journal/compress.c
> +++ b/src/journal/compress.c
> @@ -460,10 +460,10 @@ int compress_stream_lz4(int fdf, int fdt, off_t max_bytes) {
>
> total_in += n;
>
> - r = LZ4_compress_limitedOutput_continue(&lz4_data, buf, out, n, n);
> + r = LZ4_compress_continue(&lz4_data, buf, out, n);
> if (r == 0) {
> - log_debug("Compressed size exceeds original, aborting compression.");
> - return -ENOBUFS;
> + log_error("LZ4 compression failed.");
> + return -EBADMSG;
> }
>
> header = htole32(r);
> --