Re: [PATCH] ubifs: Add support for zstd compression.

[Emil Lenngren]

Hi,

Den fre 7 juni 2019 kl 22:09 skrev Richard Weinberger <richard@xxxxxx>:
>
> Emil,
>
> ----- UrsprÃngliche Mail -----
> > In fs/ubifs/sb.c we have
> >
> > static int get_default_compressor(struct ubifs_info *c)
> > {
> >    if (ubifs_compr_present(c, UBIFS_COMPR_LZO))
> >        return UBIFS_COMPR_LZO;
> >
> >    if (ubifs_compr_present(c, UBIFS_COMPR_ZLIB))
> >        return UBIFS_COMPR_ZLIB;
> >
> >    return UBIFS_COMPR_NONE;
> > }
> >
> > Maybe add an entry for zstd here as well?
>
> Where would you add it? If we add it after UBIFS_COMPR_ZLIB,
> it will effectively never get selected, unless someone builds a kernel
> without lzo and zlib but zstd.
> If we add it before UBIFS_COMPR_ZLIB, it will be used always and users
> end up with unreadable files if they reboot to an older kernel.
> Please note that we didn't raise the UBIFS format version for zstd.
>
> So I'm not sure what is the best choice for the default filesystem.

My idea was at the end, i.e. it will only be used when LZO and ZLIB
are not selected to be included for UBIFS, for example when someone
compiles a minimal kernel who knows exactly which compression
algorithms will be used on that system. I guess that's the same reason
why zlib exists at all and is placed after lzo.
But of course the other positions also have their pros. If we perform
more benchmarks speed/size and conclude that zstd outperforms zlib for
all aspects, then maybe placing it between lzo and zlib could be an
option, but as you say we should avoid breaking compatibility with
older systems.
I did a single test today and compared lzo and zstd and on that test
lzo had faster decompression speed but resulted in larger space. I'll
do more tests later.

/Emil