summaryrefslogtreecommitdiff
path: root/src/journal/compress.c
diff options
context:
space:
mode:
authorEvangelos Foutras <evangelos@foutrelis.com>2014-08-30 10:13:43 +0300
committerZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>2014-08-30 17:41:15 -0400
commitb4232628f3d4b00c967310d56c0e95715c9d05cd (patch)
tree0080a4a98ca571d48cb8d7ad7a5f1605a8f1409b /src/journal/compress.c
parentf697185e5b45287b6a62592129e726d8a636d3ff (diff)
journal/compress: use LZ4_compress_continue()
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. 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.
Diffstat (limited to 'src/journal/compress.c')
-rw-r--r--src/journal/compress.c6
1 files changed, 3 insertions, 3 deletions
diff --git a/src/journal/compress.c b/src/journal/compress.c
index 52a4c100b3..c4c715be2f 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);