On 2019-06-10 19:34:53 [+0200], Emil Lenngren wrote: > Hi all, Hi, > After some more investigations, although increasing compression level > certainly increases compression time, decompression time does not seem > to be increased by increasing compression level. See > http://www.open-zfs.org/w/images/b/b3/03-OpenZFS_2017_-_ZStandard_in_ZFS.pdf > page 9 for a benchmark. The benchmark even shows this seems to apply > to gz as well... > > SquashFS has also added support for zstd and squashfs-tools uses level > 15 as the default level (see > https://git.kernel.org/pub/scm/fs/squashfs/squashfs-tools.git/commit/?id=e38956b92f738518c29734399629e7cdb33072d3 > at the bottom). > > While the kernel compression level should maybe stay at 3, for > mkfs.ubifs where speed doesn't matter that much, a higher level such > as 15 might not be bad after all. So I have two different proposals: > either just set level 15 OR set level 15 and also provide an option > for mkfs.ubifs to override it if one for some reason wants to generate > the image faster. > > What do you think? So the original problem was that ZSTD_CLEVEL_DEFAULT is not defined in earlier releases of zstd and I would suggest to use `0' as stated here in this thread. Larger levels take more time to compress and I don't see the benefit in doing compared to the size of the compressed image. I included my numbers in the initial commit. Also, if you use a larger compression level in mkfs compared to the kernel then your image will grow if you rewrite existing files. I've been told that for RO images (where higher compression levels matter and compression is done once at creation time) the best thing to do is to use squashfs on top of ubi. > /Emil Sebastian ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/