btrfs: accept and ignore compression level for lzo
authorCalvin Owens <calvin@wbinvd.org>
Mon, 25 Aug 2025 09:02:04 +0000 (18:32 +0930)
committerDavid Sterba <dsterba@suse.com>
Tue, 2 Sep 2025 18:45:19 +0000 (20:45 +0200)
commit6db1df415d73fcad12134a54f97dc6c8a64ab181
tree6d98a9b3f78c6a9da4368bda59c762ef74a668be
parentde134cb54c3a67644ff95b1c9bffe545e752c912
btrfs: accept and ignore compression level for lzo

The compression level is meaningless for lzo, but before commit
3f093ccb95f30 ("btrfs: harden parsing of compression mount options"),
it was silently ignored if passed.

After that commit, passing a level with lzo fails to mount:

    BTRFS error: unrecognized compression value lzo:1

It seems reasonable for users to expect that lzo would permit a numeric
level option, as all the other algos do, even though the kernel's
implementation of LZO currently only supports a single level. Because it
has always worked to pass a level, it seems likely to me that users in
the real world are relying on doing so.

This patch restores the old behavior, giving "lzo:N" the same semantics
as all of the other compression algos.

To be clear, silly variants like "lzo:one", "lzo:the_first_option", or
"lzo:armageddon" also used to work. This isn't meant to suggest that
any possible mis-interpretation of mount options that once worked must
continue to work forever. This is an exceptional case where it makes
sense to preserve compatibility, both because the mis-interpretation is
reasonable, and because nothing tangible is sacrificed.

Finally update btrfs_show_options() to ignore the level of LZO, as it
is only the default level without any extra meaning.

Fixes: 3f093ccb95f30 ("btrfs: harden parsing of compression mount options")
Reviewed-by: Daniel Vacek <neelx@suse.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Calvin Owens <calvin@wbinvd.org>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
fs/btrfs/super.c