grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael Chang
Subject: Re: [PATCH] btrfs: disable zstd support for i386-pc
Date: Thu, 7 Nov 2019 06:34:13 +0000

On Wed, Nov 06, 2019 at 01:40:30PM +0100, David Sterba 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?

It works for mbr gap, however we used to encounter some system shipped
by Microsoft Windows still having its mbr gap aligned to cylinder
boundary, which is usually 63 sectors. Therefore we could only fallback
to btrfs bootloader area if mbr gap is found to be too small and now
that the solution is no longer appropriate.

> 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.

So far didn't have the request to enable btrfs zstd compression for the
root filesystem. But with new grub supporting it, the request might come
up in the future and hope we could have solution for i386-pc at that
time.

> 
> Looking at zstd code, does not seem to be easy to squeeze the asm to
> something like 64-56=8K.

Another solution from Vladmir is making the zstd support a separate
module and loading on demand. I personally think it is better than
reducing the size as the same situation could still come up in the
future.

Thanks,
Michael

> 
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]