When I know Snappy ( previously known as Zippy ) I see it faster and better for snap then LZO
some charts: http://pages.di.unipi.it/farruggia/dcb/
We cannot use a compression scheme that is not included in squashfs code within the kernel. Also, we cannot use a compression scheme that is included within the kernel if it is not widely available by default in all the distros we support yet.
1 Like
Cannot snapd include it without been kmod? I think it good enough even when it not provided by the kernel and snapd can use it if it available as kmod too for devices that support it
Snapd cannot do anything without:
- the developers first implementing your favourite compression algorithm for squashfs
- this implementation making its way into all distributions snapd wants to support
A good algorithm is already in use: LZO. A slightly better one might appear as an option at some point: zstd. If you think it’s wise to spend all this engineering cost & effort to introduce yet another algorithm, you must present a very concrete use case that cannot be reasonably achieved via the existing algorithms.
I read Snappy algorithm compress more then other algorithms if you see the charts above