[PATCH v0.5] mtd-utils: mkfs.ubifs: Add support for LZ4HC compression

[Konstantin Tokarev]

05.10.2013, 22:24, "Konstantin Tokarev" <annulen at yandex.ru>:
> 05.10.2013, 18:48, "Elie De Brauwer" <eliedebrauwer at gmail.com>:
>
>>  All,
>>
>>  After some time to do some testing this is a second version of the
>>  same patch. Now lz4hc gets actually used.  However at this moment in
>>  time only improvement in terms of cpu time is seen, but lz4hc in this
>>  context seems to behave worse than LZO, on my local system:
>>
>>  -rw-r--r-- 1 edb  edb  28M Oct  5 16:22 imag.lz4hc
>>  -rw-r--r-- 1 root root 25M Oct  5 16:22 imag.lzo
>>  -rw-r--r-- 1 root root 43M Oct  5 16:11 imag.none
>>  -rw-r--r-- 1 root root 22M Oct  5 16:30 imag.zlib
>>
>>  The only thing which comes immediately to mind is that due to the size
>>  of the chunks (in my case large block being compressed is 4k) lz4hc
>>  isn't starting to pay off ..
>
> Looks like it might be useful to have mixed lz4hc/lzo mode - lz4hc is faster,
> lzo provides better ratio, and both don't use additional memory for decompression.
> I did no speed benchmarks yet though.
>
> It also might be that lz4 has tuning parameters which may be useful for rootfs
> compression in case when most of files are not modified most of the times, i.e.
> trade compression time to space efficiency while keeping decompression speed.

In attached patch I've replaced "favor lz4hc" mode with lz4hc/lzo mix, depending
purely on which algorithm gives smaller size for the block. In my case it allowed
to get slightly smaller image size than lzo (27564 blocks were compressed with lzo
and 1054 - with lz4hc).

-- 
Regards,
Konstantin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-LZ4HC-LZO-hybrid-compression.patch
Type: text/x-diff
Size: 2170 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20131006/0b27f59a/attachment.bin>