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

[Elie De Brauwer]

Konstantin,

Sounds interesting, I'll integrate this into a next version of the
patch. Perhaps it make sense just to replace favor_lzo and favor_lz4hc
into something generic like favor_COMPR1_COMPR2 where COMPR2 gets
chosen if it is more than favor-percent better than COMPR1. Even
though today you're probably use lzo/zlib to optimise for size at a
reasonable cost of some speed  while you're probably use lzo/lz4hc if
you want to optimise for speed at a reasonable cost of size, but that
probably makes it more extensible in the future. Does this sound
reasonable ?

my 2 cents
E.


On Sun, Oct 6, 2013 at 5:25 PM, Konstantin Tokarev <annulen at yandex.ru> wrote:
>
>
> 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



-- 
Elie De Brauwer