Re: [PATCH] btrfs: disable zstd support for i386-pc

[Nick Terrell]

> On Nov 6, 2019, at 4:40 AM, David Sterba <address@hidden> wrote:
> 
> On Tue, Nov 05, 2019 at 09:19:59AM +0000, Michael Chang wrote:
>> The zstd support in btrfs has dependenciy to zstd module and core.img
>> grows its size significantly to 75KB on my system. The resulted image
>> cannot be installed into btrfs bootloader area in the size of 64KB and
>> eventually fails with following message.
>> 
>> /usr/sbin/grub-install: warning: your core.img is unusually large.  It
>> won't fit in the embedding area.
>> /usr/sbin/grub-install: error: filesystem `btrfs' doesn't support
>> blocklists.
>> 
>> The patch disabled the zstd support of btrfs in pc-bios platform to
>> avoid the regression. The resulting size is 56KB, albeit a bit too close
>> to the 64KB but works. This is simple workaround until a proper fix
>> landed upstream.
> 
> So combination zstd+btrfs+i386-pc never worked? Removing support for
> zstd could lead to unbootable system, but if that has never worked
> before it'd be ok to make the build conditional.
> 
> Looking at zstd code, does not seem to be easy to squeeze the asm to
> something like 64-56=8K.

Yeah, upstream zstd won’t get down to 8K. We recently did some work to
make the decompressor smaller for mobile reducing inlining and excluding
variants of some functions. On x86_64 the upstream library went from
84KB -> 63KB uncompressed, and 31KB -> 25KB compressed. If we update
GRUB to the latest zstd and define a few macros we can get that gain. But it
won’t be 8KB.

A custom zstd decompress optimized for size could be made much smaller
But that would be a large maintenance burden. For example, we have an
“educational decoder” that is 18 KB uncompressed and 8 KB compressed,
but it can’t be used in production, since it isn’t hardened against invalid 
inputs.
But, it shows the zstd format can be decompressed with a small library.
If we (upstream) add a smaller zstd decompressor, we will put a patch up to
use it in GRUB.

-Nick