Re: [PATCH] Btrfs: make lzo the default compression scheme

[C Anthony Risinger <anthony@xtfx.me>]

On Fri, May 27, 2011 at 2:41 AM, Fajar A. Nugraha <list@fajar.net> wrote:
> On Fri, May 27, 2011 at 2:32 PM, Sander <sander@humilis.net> wrote:
>> Li Zefan wrote (ao):
>>> As the lzo compression feature has been established for quite
>>> a while, we are now ready to replace zlib with lzo as the default
>>> compression scheme.
>>
>> Please be aware that grub2 currently can't load files from a btrfs with
>> lzo compression (on debian sid/experimental at least).
>>
>> Just found out the hard way after a kernel upgrade on a system with no
>> separate /boot partition :-)
>>
>> Found this: https://bugs.archlinux.org/task/23901
>
> IIRC what matters is compression actually used by the files.
> If /boot/grub/* and kernel/initrd is not compressed, or compressed
> with zlib, then grub2 can read it just fine, even when the filesystem
> is usually mounted with -o compress=lzo (I'm using Ubuntu Natty).
>
> I think the move to use lzo compression by default is a good thing, since:
> - it's superior performance-wise to zlib
> - btrfs is not really recommended (yet) for production uses, so it's
> valid enough to assume users brave enough to use btrfs will know the
> necessary workarounds (like having separate /boot, or temporary
> remount with -o compress=zlib when upgrading kernel)
> - even if by accident you ended with unbootable system due to lzo, you
> can "fix" it using livecd and "btrfs filesystem defragment" to force
> the needed files to be uncompressed/compressed with zlib.

i'd agree with the LZO default and everything else you've said, but i
was bitten by this too :-)

in my case however, i was using syslinux, and even though /boot was
not compressed syslinux still failed with something like:

"Found compressed data! cannot continue!"

... or similar, i don't recall exactly.  funny thing is, if i typed
out the full kernel boot line (which was super annoying for about a
week until i updated to a separate /boot) the system would start up
just fine ... so i don't know if syslinux was checking the incompat
bit or what, but it failed even though the files themselves were
technically ok.

something for others to keep in mind at the least.

C Anthony